How many bits of information are in a password?
The number of bits of information in a password are a function of the alphabet that the password is drawn from and how many characters long it is. The formula is:
nbits = ceil(log2(len(alphabet)) * nchars)
So what does that mean? Let's take the case of 8 character long Unix passwords, and do a table:
|alphabet||total bits||(bits per character)|
|lower case ASCII||38||4.7|
|lower case plus digits||42||5.2|
|upper and lower case ASCII||46||5.7|
|letters plus digits||48||5.95|
|letters, digits, and all punctuation characters||53||6.55|
(The version of 'all punctuation' I'm using is Python's, and has 32 characters.)
As we can see, conventional Unix passwords are not all that strong. Nor does lengthening them help a lot; at the most generous assumption, you need 20 characters to get a 128-bit password.
The same result can be applied to passphrases for SSH keys and the like. If your passphrase is lower case plus spaces, you have about 4.75 bits of information per character and you need 27 characters to get 128 bits.
(The number of bits of information in a password is how many bits of randomness it has and thus how many random bits you need to generate as strong a random password as you can get, and an indicator of how strong a cryptographic key it is.)
How not to set up your DNS (part 16)
Sort of presented in the traditional illustrated format:
; sdig ns ibc.com.au. ns1.ibc.com.au. ns2.ibc.com.au. ; dig cname ibc.com.au. @ns1.ibc.com.au. [...] ;; flags: qr aa; QUERY: 1, ANSWER: 1, [...] [...] ;; ANSWER SECTION: ibc.com.au. IN SOA ns1.ibc.com.au. \ hostmaster.localdomain. [....]
(The TTL has been omitted and the line wrapped for clarity.)
This is not how you are supposed to say 'I do not have a CNAME record'. What ibc.com.au should be doing is returning a reply with nothing in the 'answer' section and their SOA record in the 'additional authority' section.
The net result of this issue is that a number of resolving nameservers will return SERVFAIL when asked to see if ibc.com.au is a CNAME, which has various interesting downstream consequences.
(Technically the com.au zone says that ibc.com.au has two other nameservers, however a) ibc.com.au disagrees, since the extras are not in the NS records that the first two return and b) the extra two are non-authoritative anyways.)