Tag Archives: web stuff

Uncategorized

Why do DNS changes take so long to show up?

My project manager asked me yesterday, “Why do DNS changes take so long to show up?” We were in the process of moving a web site to a new server and he hadn’t expected it to take 90 minutes for all the traffic to move to the new server.

As background, let’s talk about what the Domain Name System (DNS) is for a moment. Every computer connected to the internet has a unique address, called an IP address. You can think of this as being similar to a telephone number. For www.example.com, the IP address is 93.184.216.34.

The problem with IP addresses is, they’re hard to remember, which is why we have a system of domain names (example.com) for groups of computers and host names for individual computers. This is similar to a person having a family name and a given name.

The DNS system is similar to your phone’s contact list. Most people don’t know all the phone numbers in their phone’s contact list; instead, they know to look up Bob Smith in the contact list and when they press the dial button, the phone looks up Bob’s phone number and dials 732-555-1234.

Similarly, when you type www.example.com into the web browser, your computer contacts the DNS system, looks up the IP address, and connects the browser to 93.184.216.34.

Rather than look up the IP address on every request, your computer will remember (or cache) the address for a while. How long it should remember the address is controlled by whoever owns the domain name, it can range anywhere from a few seconds, up to days or longer. Commonly, it’s set to several hours. This is called the DNS record’s “time to live.”

So if you run www.example.com and move the website to a new host (this could be a new hosting provider, or simply a new server at the same provider), part of the move will be to update the DNS system (contact list) with the new server’s IP address (phone number).

Because of the DNS time to live, other computers may continue to contact the old server until the DNS record expires, at which time they’ll look up the address again and find the new IP address. (This is an important consideration when moving a web application which maintains any sort of application state information.)

Bonus: Looking up IP addresses

Most Linux and OSX computers will have a program called dig installed. (Alternatively, you can also use the Dig tool from Google’s online “G Suite Toolbox”) You can use this to look up the IP address of any computer connected to the internet:

blair@Squawk:~$ dig www.example.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16595
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.example.com.               IN      A

;; ANSWER SECTION:
www.example.com.        80319   IN      A       93.184.216.34

;; Query time: 7 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Jan 14 02:01:45 EST 2020
;; MSG SIZE  rcvd: 60

blair@Squawk:~$

In the part labeled “;; ANSWER SECTION”, there’s a line which reads:

www.example.com.        80319   IN      A       93.184.216.34

The the server’s IP address is 93.184.216.34 and the computer will remember the IP address for another 80,319 seconds (about 22 hours). If you look up the same record several times in a row, you’ll notice that the number decreases over time. (It appears the record for www.example.com is configured with a time to live around 24 hours.)

Uncategorized

Password rules

Some very basic rules for managing your passwords:

  1. Don’t even think about using “password” as your password. That’s the number one most used password in the world.
  2. Consider using a password manager. No one will ever guess that your password is qwb5Qauz36H9Kleqyotx and with a password manager, you won’t have to remember it.
  3. If you must use a password you can remember, at least use a passphrase. “SixSillySwansSangSonnets” is much more secure than “Tr0ubad0r” (and a darn sight easier to remember the correct spelling).
  4. Never, ever, ever use the same password on two different sites. In short: if one site has a breach and the bad guys get hold of your username and password, they’re going to try using them on other sites as well.

    5. Faithfully following those rules doesn’t guarantee that none of your accounts will ever get hacked, too much of that’s out of your hands. But they’re a solid start and they’ll definitely help limit the damage.

    A non-technical relative admits to not understanding why people would use a password manager. Couldn’t someone just hack your password manager?

    Yes. That could potentially happen. The aforementioned password rules also apply when setting the password for your password manager.

    And you have to ask yourself, which system is more secure? A well-vetted, “battle tested” password manager (and I’m referring to the likes of LastPass, 1Password, or KeePass), storing passwords which are composed of 20 random letters and numbers? Or just using the site’s name with a couple letters and maybe a number?

    And which is easier? Keeping track of a single strong password for the password manager? Or trying to remember what password you used for 30, 40, or more different web sites? (Hint: you’re gonna remember the Six Silly Swans example for a long time.) The main reason people re-use passwords is that they need to keep track of so doggone many of them!

    The idea behind a password manager is that you only have to remember one really good password, and then the password manager remembers the rest of them.

    And the good password managers (I personally use LastPass and KeePass) use heavy-duty encryption. If you use a good password, it’s extraordinarily unlikely that anyone’s going to break into your password manager by brute-force guessing.

    (Image via Life of Pix on Pexels.com under Creative Commons 1.0 Universal)

Uncategorized

Three Minutes of Fame

Today I was internet-famous for slightly more than three minutes; just long enough for Richard Cambell and Carl Franklin to read and reply to a comment on an episode of the .Net Rocks Podcast.

Back in January, I left a comment on their website, regarding StartSSL and Let’s Encrypt, two providers of SSL certificates they’d mentioned during the show. Today, show 1287 came out, covering the topic of “InfoSec for Developers” and they used my comment (right about the 5:40 mark) as the segue to the conversation with their guest, security professional Kim Carter. (Interestingly, he turns out to be using security certificates from one of the sources I’d commented on.)

So if you don’t know that’s all about, an “SSL certificate” is one of the things you need in order to setup a secure website using HTTPS. This is part of what triggers the lock icon to appear when you’re viewing a secure web site. (You do look for that when buying things online, right?)

Richard made a valid point that a paid-for certificate really doesn’t get a whole lot more validation than what the free ones get, so if you’re able to take advantage of the free ones, there’s not really a lot of incentive not to. (it does leave the question of what extra value you get with a paid SSL certificate.)

The self-signed certificates mentioned in my question don’t have anyone vouching for their authenticity, though it’s not clear that the free or even the paid for certificates have anyone vouching for them either. There is another kind of certificate though, the “Extended Validation” certificate (which is what your bank should be using) which does involve some in-depth checking of identity.

One thing that does distinguish third-party (i.e. “real”) certificates from the self-signed ones is that if something goes wrong (e.g. the private key is stolen), a third-party certificate can be revoked. Since the webmaster is the only one vouching for a self-signed certificate, there’s no way to tell whether the person saying the certificate is valid is who they say they are. The third party certificates come from a source which has been validated, and there’s a secure chain of connections for verifying that the certificate can be trusted.

Behind the scenes, Commentary

Some Tips for Webmasters

I’ve been sick for the past week, which means that in between naps (and other, less savory aspects of the flu) I’ve been able to dedicate some time to catching up on my data entry. (An important tip: make sure your freezer is full before you get sick. Preferably with a variety – I am so tired of chicken.)

As always, I was quite impressed by the number and variety of events out there. A con chair who’s been running the same con with the same programming year after year could do many worse things than to dig around on some other con’s sites looking for ideas. (Along with the voice actors, did you know anime cons will frequently book a show’s director? Would that appeal to your attendees? I saw Harve Bennett at Farpoint [SF/Media] a few years ago and there wasn’t a dry eye in the house after his story about Ingrid Bergman.)

What also surprised me though was the number of events where the web site is either missing basic information, or else makes it hard to find. Consider these bloopers:

  • One convention prominently announces their 2009 dates on the home page. Updates dated 2009 list new guests. And as of July of 2009, the artwork in all the page banners still refers to the 2008 event. So is the con defunct? Or is the web site just out of date?
  • This one happens way too often: The home page announces the upcoming event’s guests, location, and everything you could possibly want to know except the dates. Sometimes they’re buried five clicks deep on the site, but if you want potential attendees to work that hard to find your dates, you’d better have something they really desperately want to see.
  • A similar problem: “Well, we know where we’re located.” A convention will list their venue as something such as “The Airport Marriott” and neglect to mention what particular town that would be in. (Lots of airports have a Marriott.) Sometimes you can get this information by visiting the hotel page and clicking the link to the hotel’s web site, but often that link is missing too.
  • One big blooper: throwing away your Google hits. Just this morning, I found a con where they had done something very right. They had tons of big name guests, all in their core genre; they were listed prominently in a very selective, well-respected convention list (Mine is no where near as high-profile); and the web site is simply exquisite. Unfortunately, all of the site content lives in image files. Google can’t read image files and since they didn’t include any alternate text, Google won’t return any search results for their guests. An opportunity squandered. (As a side note, for US-based conventions, this also opens you up to possible litigation since people with visual disabilities won’t be able to read your site, even with the appropriate assistive technologies.)