Playing the devils advocate on this one, its generally *bad practice* to make assumptions during coding - and the assumption that a machine has the ability to contact the internet is still (even in this day and age) "A Bad One (tm)"
If you *can* make this assumption (eg: its an in-house product) you still need to decide upon the behaviour of your application if it cannot connect to the internet (e.g. a workman just sawed through your fiber!).
If it is a commercial package, I'd consider offering something along the lines of the Windows Product Activation - a challenge/response system whereby an installation generates a code based upon "identifying parameters for the computer (as a hash)" that needs to be passed to yourselves (automatically, or by telephone) which generates a response to be entered (automatically, or by telephone). Once this 'code' has been verified, you can store this fact somewhere, along with the unique-to-that-computer hash in a licence file.
The beauty of this method is that the license file can only be used on the one machine (because of the hash), and the return code can be configured to carry a 'payload' (eg an expiry date for the software, or 'activation' flags for certain modules)
You can also periodically 'dial back' to your authentication server (auto/manual) to allow continued use of the package.
Of course, any software-based system *can* be defeated, but the idea is to make it difficult for the 'average' Joe to circumvent.
B.
