When DHCP is used to assign IP addresses to machines, the default action is to simply pluck a free IP address from a pool of addresses and assign it to the requesting machine (a DHCP client runs on each machine, and they request IP addresses from a DHCP server). Every assigned IP address is "leased" for a defined amount of time. When the lease expires, the client requests a new lease. If you're lucky, the same IP address will be re-assigned. If not, you'll end up with a brand-new IP address. DHCP servers do tend to recycle the IP addresses, but if you had turned the machine off and back on later, you'd probably not benefit from that.
The network administrator has the ability to nail a "permanent" IP address to a given machine by setting up a mapping between the MAC address of the client machine and the assigned permanent IP address. The MAC address is set by default at the factory by the manufacturer of the network card (or equivalent) that the ethernet cable plugs into (or, in the case of WiFi, it's assigned to the radio
unit on the client machine). I've worked in a shop where we override those values and tied the MAC address to a corporate asset ID, but in either case, the result is the same. Each network interface on each client or server machine has a unique MAC ID.
That's what's needed to keep a fixed IP. To be able to refer to a machine by a user-friendly IP-independent name, you need Name Resolution Services. Typically, a machine will have recourse to a number of different name resolvers, with a defined priority to avoid possible conflicts. The most famous of these (and usually the highest priority) is the hosts file, which is /etc/hosts on Linux/Unix systems and named "HOSTS" or "LMHOSTS" on Windows machines. The hosts file is a simple text file with the names and IP addresses that should be resolved in it.
The other popular resolver is Domain Name Services (DNS). DNS is provided by one or more servers which listen on UDP* port 53 and return an IP address for the name requested. Obviously, to query DNS, the client needs to know the IP addres of the DNS servers, since unlike DHCP, DNS clients don't simply send out a general broadcast and hope for a response. That sounds like a chicken-and-egg problem, but the IP address(es) of the DNS server(s) are defined when the network interface goes online. They are either supplied as part of a fixed Iocal configuration or passed back from the DHCP server.
One thing that most people don't realize is that name resolution only resolves
IP Addresses. DNS doesn't resolve port numbers. When you make a web request, for example, you have to either explicitly supply a port number (for example, 8080) or the client will pick the port number that's common for the protocol being used (80 for HTTP, 443 for HTTPS, and so forth). It's hard-coded into the client application program (browser or whatever).
==
* Usually UDP. In certain cases, TCP protocol will be used instead.
