When we register a domain, we provide the address of our Name Server (this is called authoritative name server of our domain). This NS has the info of our hosting server IP. Here is the process summarized by skipping unrelated details. When a user open a domain, the server ask its Hosting Server IP to our ISP DNS Resolver. If it has, the IP address is returned. Else ISP ask from her connection provider or directly from ROOT SERVERS. The root servers don't have the IP, but they always return the Name Server address of your website's TLD registry. Then our ISP ask same questions form that NS. It also don't know the IP but it know the Authoritative NS Address (that we configured when we purchased the domain and setup its NS), the address of authoritative NS is returned. Then our ISP ask same questions form our domains' authoritative NS which definitely has the IP address of hosting server. When its returned, our ISP's DNS Resolver cache it to serve other queries and re...

In Name Server (along with other info, the most important is) we define a mapping of Our Domain/Sub-Domain Name and Its Hosting Server IP Address What other info? Its usually include following things: The email server address... called MX records. Defining domain aliases. Configuring it to redirect to other domain. Adding some info provided by third parties to verify that we own the domain. Sometime we want our particular sub-domain to link to another DNS, who better knows the hosting server IP. we can also do that e.g. when we configure our domain to Blogger free sub-domains, we map our domain to google name server. etc. The rest is done by Google in their NS. But you don't need to bother all these details as far understanding basics is concern.

If we skip architectural details of library and framework design.  The fundamental difference is: We call the library code. How? By initializing its components and calling methods that provide some utility to our app. e.g. Apache String Utils libs, Apa che Compression Library, etc.  But the framework calls our code. How? Because we write our code following some conventions dictated by the framework or we build our application components by extending or implementing the components already provided by the framework. e.g. Spring MVC, Laravel, Ruby on Rails. etc.