Well, kind of. In order to get your Dot-US (.US) ccTLD DS record to be added to the Dot-US zone, you need to have NeuStar as your Registrar. NeuStar is the Registry for Dot-US (and Dot-BIZ), but not the Registrar of all Dot-US domains. In my case, I have two Dot-US domains. Roysdon.us and Roysdon.Modesto.CA.US. The first is registered through GKG.net, so they are my Registrar there. GKG, nor any other Registrar other than NeuStar have officially been listed as having Dot-US DNSSEC support yet, so I have to wait. However, my "US Locality" domain, Roysdon.Modesto.CA.US, does have NeuStar as my Registrar, as it is a legacy domain, back from when Dot-US domains were where for free and allowed citizens, businesses, organizations and government agencies establish unique, memorable American identities online.
Eventually the Dot-US Registrars will get ramped up and give support to the johnny-come-lately folks who don't have US Locality domains, but the DNS infrastructure is there now.
Well, kind of (yeah, just a few of these "kind of's"). If you want to allow anyone with a little technical skill to list your entire Dot-US zone. If you don't mind them seeing every single record you have, well, then you can add DNSSEC DS records into the Dot-US zone and have a trust chain all the way from the Root, through Dot-US, to your domain. Why is this information security hole required? Well, right now Dot-US is only allowing NSEC record algorithms 3 (DSA/SHA1) and 5 (RSA/SHA1), but not NSEC3 record algorithms 6 (DSA-NSEC3-SHA1) and 7 (RSASHA1-NSEC3-SHA1). NSEC3 is important for those who wish to keep their zone data from being enumerated (listed) and therefore exposed to anyone who has just a little technical skill. The full list of DNSSEC algorithms should be supported by all Registry/Registrars so, and hopefully the lesson to be learned by other Registry/Registrars before they implement DNSSEC support for customers.
I'm confident that the Dot-US Registry, NeuStar, will address this and open up the zone to allow domain owners to submit any valid DNSSEC DS algorithm type, and I have requested they do so.
As others have said, DNS is public info, but that's not 100% true. It's mostly public info. It's sort of like the Freedom of Information Act: You have to know what to ask for to get it. You can't, normally, say, "Give me all your DNS records." A proper DNS administrator will block AXFRs (Zone Transfers) to anyone except the servers that need AXFR access for replication. As I said, if you sign your zone with DNSSEC NSEC, then all your base are belong to us [sic].
To prevent zone enumeration via "NSEC walking" you want to sign your zone with NSEC3. However, you cannot generate NSEC DS records from NSEC3 keys (and visa-versa). So if you want to submit your DS record to NeuStar, you need to sign with NSEC, which means you need to expose all your records to being listed.
For now, I came up with a work-around: Sign my Roysdon.Modesto.CA.US zone with NSEC so I could submit my NSEC DS record to NeuStar, but have no records in it except the bare-minimum requirements (SOA, NS, MX), and the delegation of a child domain via NS & DS records. The child domain, home.roysdon.modesto.ca.us, is signed with NSEC3, and its NSEC3 DS record can in the parent NSEC-signed zone without issue. As home.roysdon.modesto.ca.us is NSEC3-signed, it is immune to NSEC walking, and my records secure.
It's not like my NSEC3 zones have some top-secret records, but I do put a lot of information in there. HINFO records are a nice way to store the Hardware and OS, LOC records for storing LAT/LON coordinates (which can be dynamically updated and obtained from and cell phones using GPS or Wifi APs can be used to cross-reference approximate LAT/LON coordinates), RP records for who owns a system, TXT records for whatever you might want to store (try and find out what Ox.roysdon.org, Eagle.roysdon.net, Lion.roysdon.us have to say in their TXT records), but you could store Serial/Asset numbers in them, WAN Circuit IDs, even vendor support contracts and numbers. Not to mention just a list of all the hosts themselves - why do you need to know how many systems I have? It's nunya.
I also store SSHFP records, which allow me to SSH to one of my hosts from a new host and not yet have the SSH key. By using SSHFP records in a DNSSEC-signed zone, I know that the SSHFP record wasn't tampered with in the DNS reply, and I can verify that the SSH key that my server is sending wasn't tamped with by verification of the SSH Fingerprint record.
I think a revamp of the SSL Certificate Authority (CA) model is order now as well. SSL CA digests should be stored in DNS for the zones of which they are to issue Certificates. SSL CAs should become hierarchical, the same as the DNSSEC trust model is. A browser with zero Root CAs installed, and only the Root DNSSEC Trust Anchor. From there, it could bootstrap the entire CA architecture for each record needed for SSL requests. For instance, use DNS to find out the NS of roysdon.modesto.ca.us and be able to verify each reply from the DNS Root down to my NS servers (which can be done now, that infrastructure is there and all records are DNSSEC-signed), and then request a "CA" record and "CAFP" fingerprint record from the zone. My proposed "CA" record would be the name of the Certificate Authority, and the "CAFP" would be fingerprint digest such that after the CA Certificate was downloaded, the CAFP would verify that it was the correct CA Cert.
The great thing with this model is that a domain owner would have the ability to chose how they want to host their domain's CA. They could do it internally or use a third-party CA, either because they didn't want to host the infrastructure for a CA themselves, or because they wanted some sort of Extended Verification (EV) done by the CA. Verisign, et al. would not like my plan, as they'd only make money for folks not hosting their own CA themselves, or where free CA's could not be found. Invalid self-signed SSL certificates would become a thing of the past. DNS hijacking and spoofing won't work as DNSSEC will block it, and potential rogue CA's like Etisalat (thanks to Verizon/GTE) and CNNIC won't be able to create their own Intermediate CAs for just any zone they want and monitor traffic.
Not to re-invent the wheel completely, it looks like RFC4398 which specifies CERT records may be able to be used for not just CA's but also GPG keys. Whatever the RR is matters not to me, so long as it puts the control of the SSL Cert into the hands of the domain owner (or any cert for that matter, as GPG keys would be nice as well).
By the way, even if you remove Root CA's you don't trust in Windows, Microsoft will add them back for you, unless you disable this feature. I don't see any need to trust CNNIC, so I've removed this Root CA from my browsers, but am still debating removing Verizon/GTE's Root CA.
The online world just became a little more secure yesterday. The dot-ORG (.org) top-level domain (TLD) just opened up the ability for the owner of a .ORG domain to include their zone's DNS Security Extension (DNSSEC) Delegated Signer (DS) key.
(642-832) Troubleshooting and Maintaining Cisco IP Networks (TSHOOT) - Passed
I received word that that I passed the new 642-832 TSHOOT Beta exam that I took on March 26! Woot, CCNP recerted, and by passing this test my CCDP and CCVP are renewed as well for 3 more years.
So you want to make the leap on to the interwebs, I mean webtubes. You want something bigger than your FaceSpace, err, MyBook page. You know those social-thing-a-ma-bobs, right? But you don't have big enough pipes coming to your house? What do you do?
You can pay someone like Hurricane Electric $1/month to host it (or GoDaddy, GKG.net, and hundreds if not thousands of others out there). But how do you choose? Here's how:
I was thinking this morning about a number of things. Specifically, as to why places like LinkedIn are becoming more and more popular.
First, let me step back and explain something. There is an age-old saying, the Net interprets censorship as damage and routes around it originally made by John Gilmore in TIME magazine (6 December 1993). In Internet terms, 17 years might as well be a century.
Cisco is revamping their Cisco Certified Network Professional (CCNP) certification program. They held two webinar/conference calls yesterday discussing the changes. Here are my notes:
642-812 BSCI is being replaced with 642-902 ROUTE
642-812 BCMSN is being replaced with 642-813 SWITCH
I really feel for folks who have bad setups for their website. In this specific case, I'm referencing a problem where Tucows/OpenSRS was used to register the domain with one of their Registration Service Providers (RSP), acmeinternet.com. I say all this to warn folks regarding how bad this is when things go wrong. Use a company that you can call up and talk to a live body and that has been around for some time.
If you were a Comcast and did either of the following:
Then you can collect $16 by visiting
The long-awaited CentOS update to 5.4 shipped yesterday! Release Notes and Mirrors (including .torrent files). Another great release in the line of a completely free, rock-solid stable Enterprise-grade Linux.
If you have an existing CentOS 5.x system configured to automatically update with Yum, or if you occasionally manually update via Yum, be sure to look at the Known Issues and follow these steps:
For those of us with the need for DNSSEC NSEC3 support (required for .GOV, .ORG and others) on RHEL5 / CentOS5, official support isn't coming until RHEL6 (RH BugID 504052). For now, though, we can use the source RPM from Fedora 11 (now Fedora 12) to compile it ourselves.
Install rpmbuild and other dependencies:
yum -y install make gcc rpm-build libtool autoconf openssl-devel libcap-devel libidn-devel libxml2-devel openldap-devel postgresql-devel sqlite-devel mysql-devel krb5-devel xmlto
Download the latest F11 bind and dnssec-conf src.rpm:
cd /usr/src/redhat/SRPMS
wget -c ftp://mirrors.kernel.org/pub/fedora/updates/11/SRPMS/bind-9.6.*.src.rpm
wget -c ftp://mirrors.kernel.org/pub/fedora/updates/11/SRPMS/dnssec-conf-*.src.rpm
Update: F12 has been released with the latest bind and dnssec-conf src.rpm:
cd /usr/src/redhat/SRPMS
wget -c ftp://mirrors.kernel.org/pub/fedora/updates/12/SRPMS/bind-9.6.*.src.rpm
wget -c ftp://mirrors.kernel.org/pub/fedora/releases/12/Fedora/source/SRPMS/dnssec-conf-*.src.rpm
Now install the SRPMs (the trick here is --nomd5 to stop signature verification which will fail due to Fedora's new sha1sum version in RPM):
rpm -ivh --nomd5 bind-9.6.*.src.rpm dnssec-conf-*.src.rpm
Build the RPMs:
cd /usr/src/redhat/SPECS
rpmbuild -ba ./bind.spec
The built bind RPM is now in /usr/src/redhat/RPMS/i386/ or /usr/src/redhat/RPMS/x86_64/ depending on your Arch.
rpmbuild --ba ./dnssec-conf.spec
The built dnssec-conf RPM is now in /usr/src/redhat/RPMS/noarch/
To install bind and dnssec-conf, you need curl and python-dns*(requires EPEL):
yum -y install curl python-dns
Then:
cd /usr/src/redhat/RPMS/*86*
rpm -Uvh bind-9.6.*.rpm bind-chroot-9.6.*.rpm bind-utils-9.6.*.rpm bind-libs-9.6.*.rpm ../noarch/dnssec-conf-1.21-*.noarch.rpm
A newer dnssec-conf is available via EPEL that is more up to date (ITAR, etc.) than the current F11 SRPM (F12 is current), so update it from there if this is allowed by your policy:
yum -y update dnssec-conf
Now you need to subscribe to Fedora bind updates so you can repeat as bug fixes are released. (I've written a detailed post describing how to do this).
--
Update Jun 1, 2010: RedHat has published a BIND 9.7 tech preview for RHEL5.6 per my request:
http://people.redhat.com/atkac/bind/5.6-test/.
There are many different options to help you secure your PC. Good password protection, software protection, and network/dns protection.
There are two important things you can do to secure your computer, no matter if you run on Windows, Mac, Linux, *BSD, or whatever.
Highlevel:
When you SSH to a host/server, the host/server sends its Public Key, much the same as an SSL connection allows you to do with a web-based https connection. This allows you to encrypt data from your client and send it to the host/server which has the Private Key to decrypt it.
With SSL/https we have Certificate Authorities (CAs) that do some sort of verification and then sign SSL certs. Our web browsers (Internet Explorer, Firefox, Opera, Safari, etc.) come with a list of CA Roots. This allows us to verify without going external to our clients that a Public Key is legit, as it has been signed by a pre-trusted CA Root.
I originally posted a more simplistic overview of DNSSEC that is a good first read if you're new to the subject.
I'm going to borrow and re-work a little content I made from a future post about SSHFP but that is relevant to DNSSEC.
With SSL/https we have Certificate Authorities (CAs) that do some sort of verification and then sign SSL certs. Our web browsers (Internet Explorer, Firefox, Opera, Safari, etc.) come with a list of CA Roots. This allows us to verify without going external to our clients that a Public Key is legit, as it has been signed by a pre-trusted CA Root.
...
DNS suffers from the same MitM attack problem as anything else. However, we can sign DNS with DNSSEC and we already have trusted equivalents of CA Roots, in the form of the DLV.isc.org system, and eventually with DNSSEC signed DNS roots.
DNSSEC is not the same as CA roots, but it is close in some ways.
Recently I upgraded from Fedora 9 to F11. With the upgrade, my VMWare Server setup has had nothing but problems. I've limped along, but finally bit the bullet and learned VirtualBox. VBox is free and OSS. It supports branching or forking snapshots, meaning you can have thousands of VMs taking up very little disk space (just the differentials from the base os or wherever you fork/branch). This is a feature you need VMWare Workstation (pay) to enjoy.
So just what is VirtualBox or these "Virtual Machine" technologies? In short, they give you the ability to run many operating systems (Windows, Linux) at the same time on the same physical hardware, plus many other options (like redundancy and such on larger systems).
One use I have for Virtual Machines is to run Windows in a VM Guest without having to run Windows as my main OS, and never having to reboot ("dual booting") to Windows. I do this because often there are proprietary things I need to do that won't work on Linux for one reason or another (VPN software that only works on Windows is the primary reason, or software that requires Internet Explorer and/or ActiveX or something else which IEs 4 Linux don't support or do well). I also use Quickbooks for my business needs (I use GnuCash for my personal needs, but I need to be able to quickly get my bookkeeper what they need and with Quickbooks I can talk the same language without having to learn too much accounting beyond the basics). I need Quickbooks to just work, and I don't have time to deal with it breaking under Linux, as if it is broken, I don't bill out customers. VirtualBox allows me to run Quickbooks in Windows XP in a very stable way - I use snapshots so that my Windows XP OS never changes, only the separate partition that contains my actual Quickbooks data files ever changes, but that's another story for another day. Another advantage I have running Quickbooks this way is that my VM Guest for it is never allowed Internet access, so it is virtually hack proof (essentially you'd need to have physical access to my laptop to get to my Quickbooks).
Dan Kaminski found one design flaw with the majority of DNS servers as well as exactly how to exploit it in a repeatable fashion. There are many other problems with DNS attacks that would be solved with DNSSEC.
Just what is DNS?
Some months ago I was blessed to meet a retired gentleman at church who helped another friend at church come up with some artwork for his business. He's come up with a number of logo ideas. I am not an artist and while I can tell what I don't like, I'm not sure how to get at what I think needs to be done to improve or fix what is wrong.
I'd like to hear from everyone as to their top 3 picks and suggestions for improvements for the Roysdon Networks logo. Please note that these are pencil sketches with some sample colors. Once I've decided what logo to go with, I'll have a professional graphics artist create it.
Conficker [?] is set to start its new "upgrade" right now, starting in the GMT timezone and rolling around the world as
End users can do quick tests
There are many ways to do the same thing, but some ways are much more efficient. Sometimes being more efficient requires a bit of work up front, but saves you an invaluable amount of time later, especially in the middle of an emergency.
The ability to backup network router, switch and firewall configurations automatically not only saves time, but can help troubleshoot when there are many cooks in the kitchen, or even if there is just one forgetful chef. The idea is simple: have a resource that automatically periodically goes out to each device on the network and makes a copy of the configuration. Further, an automated report generated daily showing the difference in configurations, in case something has to be rolled back.
The question really is not if you will use IPv6, but when. You probably already do and just don't know it. If you don't live off the grid and you do purchase gas, electric and water services, no doubt you home has an IPv6 or two assigned to some of the devices on your property, such as your gas, electric, and water meters. Why? Well it sure makes addressing hundreds of thousands, if not millions, of devices that much easier for utilities and municipalities.
I remember when I first started this journey to start my own company. I shared that I thought it was time to strike out on my own with my family. One of the first obstacles I ran into was what to call this new company? It seems like a simple enough question, and perhaps I built to high of an obstacle in coming up with a name. When it came down to it, my oldest son had it right: Roysdon Networks. Roysdon's my name, and building Networks is my game.