A website URL has many pieces of information, even in common every day use. A URL such as

has 3 different pieces of data:

• https is the protocol used to get access to the service.
• The second is the hostname of the server to get data from contained between the /’s.
• The data after the hostname and slash tells the web server what specific data you are looking for.

There could be more slashes, other odd characters, or even more advanced parts to a URL that I won’t get into here. The main point is that we have the protocol, the hostname, and we have web server data; three parts melded into one URL.

At the simplest levels, what DNS returns after looking up a hostname in the directory, though, is just a number. Much like a phone #, the number is the Internet address of the web server that should handle your request. Your computer connects to this web server, presents the rest of the URL for processing and gets the data you are looking for.

One very common misconception is that DNS gives you more data than a number. Specifically many people assume web server data, such as more web server URL data, is inside DNS A records as well. Only numbers are ever returned inside a DNS A (or AAAA for IPv6) record (what your computer is looking up for visiting a web site). Anything after the hostname in the URL is only handled within the web server itself.

We get requests all the time to set up a website “redirect” within DNS. This can’t be done. DNS hostnames can be pointed to web servers, but not with extra data that isn’t just a number (an Internet address). That extra data needs to be configured inside a web server somewhere.

Unfortunately, many people do believe that this can be done because a few web companies have set up magic systems to make it seem like it is part of DNS. But what their magic is doing is running up yet another web server somewhere, handling the web request, and the web server gives out more results to go back to somewhere else. Since many DNS service companies run out of the country, your web site visitors end up getting bounced around the globe chasing down the proper web server in the end. Usually this works, but there is delay and processing (or latency) while the requests are handled off in Australia or Europe. If that web server redirect server is down, so is your site, because you depend on somebody else having the correct configuration while being up and available.

It is better to configure your web server locally to properly handle different domain names you may have instead of having magic redirects bouncing your customers around the globe. That way all your requests stay local and nobody else can intercept your web visitor to somewhere else due to a misconfiguration (or potentially nefarious activity). Response time will be quicker (latency again) since you’ll handle the request directly off your server instead of the visitor going to different offsite servers and then finally back to your server with the correct URL you wanted in the first place.

Finally, you don’t have to keep track of who does what function. I have seen redirect chains more than 5 levels deep as nobody knows any longer what was set up, what goes where, or how to troubleshoot such a complex setup. They build up over the years with different designers doing something a bit different with each revision.

With all your domainname/URLs configured in the web server to properly handle each one, it is all in one place, one response, and updates are easily handled without chasing it all over.

I really don’t have a lot of tools for testing, I use two for the most part: telnet and openssl s_client. I could use netcat, but telnet is installed on every UNIX-like system I touch.

Testing http is simple.

$ telnet localhost 80
 GET / HTTP/1.1
 HOST:www.example.com

Should return the website for http://www.example.com

SMTP is a little more complicated. You have to know a bit about the SMTP protocol. Testing SMTP-AUTH requires a BASE64 the username and the password.

Testing SSL is nigh impossible with telnet, so that’s where openssl s_client comes in. Again, I could use netcat, but openssl works just fine, and is already there.

 $ openssl s_client -connect www.example.com:443

Gives you something like this:

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
 Server public key is 1024 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
 Protocol : TLSv1
 Cipher : DHE-RSA-AES256-SHA
 Session-ID: 38964888A9D4EBD17FC76D033CE02C5A0710C5EBD51D51A9FC6350CC8CFE019B
 Session-ID-ctx:
 Master-Key: 3A997E182CA1E9B8C3D5314D80B0F4B98973B1FC5B6AC754BE02CDA53B686FD73D8F9329D6290BE7AC53EA3871F3099B
 Key-Arg : None
 Start Time: 1332519536
 Timeout : 300 (sec)
 Verify return code: 18 (self signed certificate)

This includes SSL statistics, including the certificate’s status. The last line in this case shows that this is a self-signed certificate, and would generate errors After the SSL status appears, you are entered into an interactive session for issuing commands, a lot like telnet. SMTP over SSL works much the same way. You can also test TLS via the -starttls option.

So, with a little bit of knowledge, you can test both mail and http via telnet and openssl. No extra tools required.

Besides the documentation, which is voluminous (must like any network vendor), an excellent point to start is with Juniper’s DayOne whitepapers.

They are available at http://www.juniper.net/dayone/ and cover a range of beginning to advanced topics. They are called DayOne, as it should take a person about a full day to read and digest what is contained in them. They also have some advanced topics that are weekly guides (called This Week).

While these study guides are old, they are still valid for the basics, and getting started in JunOS, even if it doesn’t cover the very latest topics. These pointers are tucked away pretty good, so you may not run across it very easily.

http://www.juniper.net/us/en/training/certification/books.html

Certification Fast Track is part of the next topic, but I’d point out especially this part of where they offer study materials and sample tests for their certification tests. The Fast Track program starts here.

https://learningportal.juniper.net/juniper/user_fasttrack_home.aspx

But this gives you course materials, and pre-assessment exams about those topics. You can also get half-priced exams at Prometric testing.

Juniper also offer more topics than just their certification tracks through their learning portal (https://learningportal.juniper.net) with even topics on their newest hardware, such as the QFabric. eg. they have installation, design and setup topics on that solution up already, as well as firewalls (SRX), Switching (EX), as well as their routing (MX, M & T series) devices.

Finally, the ultimate soft-lab is Junosphere. They’ve made it very easy now for people to buy time with just a credit-card. Just sign-up, give them credit card data and I had to wait 3-4 business days for it to process through their systems.

https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5735

While it does cost some $$$, paying $5 per day/per router virtual spun-up is not all that expensive as a study aid.

This lets you deploy a network of routers spun up inside virtual machines, and build a whole network with a few configurations here and there, and a few mouse clicks.

It is setup for a full-on lab training for enterprise customers, but single home-users can use it just fine as well.

It is pretty cool to have at your control a number of routers spun up at your command, as used Juniper routers aren’t exactly cheap. Even ancient discontinued models still fetch a pretty decent price on eBay.

A leaner, faster website was part of the goal of the redesign. And we got that.

Changing our CMS was part of it to tell the truth. CMS Made Simple was our workhorse for years but we decided to make changes and pick a new CMS. We chose WordPress if only because we have a lot of experience with it. Load balancer wasn’t changed so any perceived lower response time really is the difference in the CMS and has nothing to do with the web servers on the backend. I say perceived though the reality matches perception – it is faster.

Better search functionality was also achieved. WP just does a better job of this than CMSMS ever did.

Websites have a hostname, like www.iphouse.com. When you click on a link or enter a URL into your web browser, the browser extracts the hostname from the URL and opens a connection to it. But the network doesn’t work with a hostname, it works with numeric IP addresses like 3522190849, which is usually written 209.240.94.1. So the web browser first has to look up the IP address for the hostname through DNS, the Domain Name System. Once it has an IP address, it can open a connection to the server and request the file.

There are two types of web hosting, named and numbered. With a named virtual host, many hostnames point at a single IP address for the server. When a web browser makes a request, it tells the web server the hostname which is being accessed and the server uses that to look in the correct place for the requested file. This is all part of the HTTP/1.1 standard,  released back in 1997, and which every modern web server and web browser supports. Named virtual hosting is a very efficient use of IP addresses, which are otherwise a limited commodity, and the organization which oversees IP address allocation requires its use.

With a numbered virtual host, the IP address is associated with a single hostname. The only case which now justifies this is a web site which uses SSL encryption, since SSL is handled before the HTTP transaction and the web server has to respond with the correct SSL certificate before it knows the hostname. Thus, there can be only one hostname associated with the IP address.

There is an extension to SSL called Server Name Indication, which would provide hostname information earlier in the connection and allow named SSL hosting, but it is not currently in wide use.

A popular techie web comic made a good one about this from xkcd:

Now, like a lot of stuff you come across online, this comic is a bit of a simplification. The length of a password directly corresponds to the difficulty to brute force it, but so does complexity. For example, if you have a password with five all lower case characters, you’ll have 11,881,376 possibilities. If you take that same five character password, but now add the option of using upper case letters and numbers zero through nine, you’re now looking at 916,132,832 possibilities. That is a very significant difference. Taking an easily memorized string of words, and adding a couple of upper case letters and numbers/symbols will go a long way towards 4SecuRing9THaT9PasswORd2.

However, having a long and complex password won’t do you much good if you don’t have secure practices. Here’s another comic that I like that really sums this up well: Movie hacking vs real hacking

Don’t give out your password. It sounds simple, but you’d be surprised how often this happens. If Phishing attempts didn’t work, you wouldn’t see them used anymore. Nowadays, you shouldn’t come across any organization that will ask you to verify your password over email. It just isn’t done anymore. If you see a password verification request, it is either a phishing attempt, or it’s legitimate – in which case you’ll want to read that request as “Hey user, we as an organization have TERRIBLE security – move your services elsewhere if you know what’s good for you.”

Another thing that can get people into hot water is using the same password for multiple accounts. Here’s a hypothetical situation that unfortunately isn’t all that hypothetical for some users…   Let’s say you’ve got a fantastic password that you’ve committed to memory, but you use it for pretty much everything. All is well and good until the site where you created an account to manage your Girl Scout troop’s fantasy football league gets compromised. No big deal, right? What’s a hacker going to do with your latest draft picks? Well, let’s say you used that same password for your email account. The same email account that you used to sign up to the fantasy football league, which Mr. hacker now also knows about. Now they can log into your email account and take a look at what other kinds of accounts are tied to this email address. Things like online banking, mortgage, credit cards, etc.

Which brings us to my last point; a chain is only as strong as its weakest link. Having a fantastic password for your online banking account doesn’t do you much good when your email address tied to the account has a weak password. Once they’re into your email account, they can ask for a password reset from the other accounts tied to this email address.

Sometimes, its not your skill which was necessarily at fault, but your environment. Perhaps the code has simply outgrown the original project scope, and become littered with references and obscure exceptions which were bolted on later. Reconsidering and refactoring the code is a necessary step to regaining control of the chaos. Or the original project simply didn’t afford enough time for development, and you had to leverage existing code which didn’t quite fit. Our own ipMom account interface started life as PostfixAdmin, which was quick and easy to put into production, though you wouldn’t be able to tell anymore.

Finally, programming languages themselves change. New libraries are added, and new functions which can make your code leaner and cleaner overall. With relatively new programming languages, its easy to have code which predates any developed or widely-used best practices for the language. Bringing the code up to spec now will make it easier for you, and easier for others, to maintain it in the future.

SPF:

Many people use SPF DNS entries (although we question their utility), but use it with only a TXT record type. There has been a SFP DNS record type since 2006. The standard document for SPF (RFC 4408) specifies that either or both are currently recommend. The standard library that scans for SPF records can handle either or both. The only reason for keeping SPF records in TXT entries are that there are many online DNS editors that can’t deal with anything other than the most basic DNS types and they have no idea of anything other than TXT, A, MX, CNAME and SRV records (let alone any of the others I will mention here :)

We typically put in both or just the SPF entry if you ask for an SPF record, although, only the SPAMers and marketeers seem to have compliant SPF records, and nobody else..

SSHFP:

The first useful application of DNSSec has actually been in use for a number of years in the form of SSHFP. DNSSec cryptographically authenticates the content of DNS, and if you follow the chain, you can be certain that the data obtained is authentic and correct. The SSH protocol used for remote access on Unix machines uses strong cryptography and the first things that you can do in most cryptography protocols is to verify the remote end is who they say they are. With SSH you get what is called a finger print, and verifying the finger print with the remote end tends to be a problem that many just skip.

With SSHFP, you put that finger print into the DNS records, so that the ssh command can verify the finger print for you. If the zone that has the SSHFP in it is DNSSec signed and authenticated, then ssh will trust that finger print to be authenticate and true, and will auto add it to your known hosts without going through the finger print verification stage you normall see for an unknown host.

LOC:

One of the oldest on this list is LOC which simply lists the geographic location of the domain name down to a given longitude and latitude with a given precision of the information given.

There used to be some fun utilities that would traceroute through the country and show you physical locations based on the LOC DNS entries.

The geographic IP address databases maintained by companies like MaxMind and the like have negated the utility of the LOC entry, although MaxMind does get locations wrong all the time. It has become a big problem for operators getting new IP blocks (of what is left in the RIRs) that the geographic database providers have wrong info, and suddenly google redirects you to the Mexican google page or something on your new block.

If LOC were widely used, that wouldn’t happen, but now it is more historical curiosity than anything.

DNAME:

Many people know of CNAMEs, but there is also DNAME. With CNAME, you can map a single DNS FQDN over to a new FQDN. But with DNAME, you can alias a whole subdomain of a DNS record over to a whole new DNS tree.

Thus, you can make something like mail.iphouse.com DNAME over the top of mail.iphouse.net, and everything in mail.iphouse.net now would start to resolve for mail.iphouse.com as well.

Not many customers use subdomains at all but we do internally for our own internal machines and network gear. Another area where this record can be very useful is within the PTR trees, and mapping areas of PTRs over to other ones. (ie. especially for classless delegation of short prefixes); or for renumbering support while you are dealing with moves, instead of duplicating, just alias on top of the PTR trees.

DANE:

while there isn’t a DANE record type, it is more memorable as the framework as a whole than the TLSA or SMIMEA record types that actually comprise it.

Like SSHFP, DANE will be the major DNSSec application in the future (this work hasn’t been finished yet at the IETF). DANE will cryptographicly authenticate TLS certificates in use for SSL/TLS websites, mail servers, jabber servers, S/MIME cryptographic encoded email, etc. etc. Everywhere an x.509 certificate is used today in order to protect services. DANE will authenticate that the certificate presented by that service is the one authorized by the domain holder.

DNSSec takes care of the cryptographically authentication, so that system needs to be in place already. Then the DNS admin needs to create TLSA entries with either the full x.509 certificate for a given service, or more likely, a secure SHA hash of the certificate to authenticate that a given cert is the correct use as deemed proper by the DNS admins as well as the server admins of a given domain name record.

I think that this framework will take off in a big way among the larger sites to provide robust cryptographic authentication of the SSL/TLS certificates to prevent the spoofing that can happen now-a-days due to weak CA security, or MiM attacks.

This is just a subset of all the DNS record types out there, but I find these to be some of the most interesting little known types out there. I’m especially looking forward to DANE being in common use, but will have to beef up our DNSSec implementations before that can become a reality.

With that, it should be pretty clear that your development server should be as identical as possible to your production environment. It does you no good to write a new feature which leverages FiddlyC 4.2pl64 with QuirkyProc enabled if your production server is designed for and built and upon FiddlyC 3.

Fortunately, this is something which a virtual data center makes really easy. If you’ve based your production server on a template from your catalog, it’s just as easy to create two or three identical VMs based on that template as it is to create one. If you want to try something really new, create a new VM. If it doesn’t work out, tear it down and recover the resources.

You can even clone your current production vApp and servers into a template, if you have space available and can afford the downtime. You’ll need to shut down the vApp, then right-click on it and select “Add to Catalog”. Give it a name, and click OK. This will take some time, depending on how many VMs and how much disk is allocated. Once the process completes, don’t forget to restart your production vApp. But now you’ll be able to create a development environment which is exactly identical (aside from network names and addresses) to the original.

http://forums.dropbox.com/topic.php?id=57860

plus this…

plus this…

results in this…