5

I am reading about how DNS works in general and I stumbled across this question and answer.

According to the accepted answer, the second step is when the DNS communicates with the ISP servers for the IP address of the host name.

DNS: "Right... wait a sec, I'll ask the ISP servers. Ok, it looks like 157.166.226.25."

I happened to read this answer which says,

CLIENT running browser asks DNS Server using UDP protocol for A record of www.pippo.it

on client it is the operating system that does resolving part and talks back to browser, browser never talks to DNS directly, rather through OS by invoking gethostbyname()
and on Linux resolving precedence is defined by /etc/nsswitch.conf

So, if I block all the outbound traffic to port 53 in my machine using the firewall rules, does that mean I couldn't resolve any host name at all?

I believe that shouldn't be the case which is why we have /etc/nsswitch.conf file (on Linux machines, though similar concept might be present for other operating systems as well). The file understands the hosts database in which host names and numbers are used by gethostbyname() and related functions.

Could someone clarify whether my understanding is correct or if have misunderstood?

Improve this question
0

5 Answers 5

Reset to default
17

Something to keep in mind with regard to HTTP is that all of the communication between the browser and web server takes place over TCP, which uses IP addresses. The name resolution as you said happens first, because without the IP address, no communication can take place.

So the Internet works fine, and you can even access web sites without DNS, even if you don't have names in your hosts file, as long as you know the IP address.

Now, to contradict what I just said a little bit, since your question is specifically about HTTP, the truth is that some web sites will not work if you try to access them directly by IP address.

This could be for many reasons but one of the most common is that the web server actually hosts many different websites on a single IP, and then differentiates requests to those sites based on the requested host name.

This is done as part of the HTTP request by adding a Host: header. The browser uses the name you give in the address bar to fill in this header during the request, but strictly speaking this has nothing to do with DNS.

One other way that browsing by IP can be problematic is on HTTPS sites because the certificates are issued to certain host names. This won't prevent them from working, but the certificate can't be verified by the browser since the name doesn't match and you'll get a warning.

Improve this answer
1
  • 8
    To clarify, "some web sites will not work if you try to access them directly by IP address" without additional headers. You're still accessing them directly via TCP / IP, it's just the browser is automatically adding a Host header.
    – Michael Petito
    Dec 10, 2014 at 16:02
8

Strictly speaking, the hostname resolution process is out of scope of the HTTP specification. In practice, though, it is nearly always done using DNS over UDP port 53.

In special cases, alternate name resolution mechanisms may be used:

  • Windows clients will check a local Hosts file, then DNS, then do NetBIOS name resolution.
  • OX X clients will also use multicast DNS (UDP port 5353) to resolve .local addresses.
  • Linux / Unix systems will use /etc/nsswitch.conf to determine the hostname resolution order. Alternate mechanisms include LDAP and NIS.

System administrators often choose to block DNS at the firewall to force all clients inside the organization to use a local DNS server. This helps control the risk of DNS cache poisoning attacks.

Improve this answer
1
  • 1
    Indeed, before we talk about the HTTP protocol, we assume an underlying connection has alreday been established (e.g. via TCP over IPv4 or IPv6, but nothing prevents us from using a different protocol such as SPX). In case of TCP/Ip, the three-way handshake is not yet part of HTTP. The information needed to establish the connection (i.e. ip and port) are extracted from the URL: the port from URL part "after colon" or implicitly 80, the ip from the host part of the url (converted to an ip via name resolution if its syntactic form suggests so, and this may involve a DNS request)
    – Hagen von Eitzen
    Dec 10, 2014 at 18:39
7

default settings for nsswitch will look up /etc/hosts (files) first then try dns. So if the host is listed in /etc/hosts and you block port 53 udp/tcp then it will still get the correct ip and work. If the host is not in /etc/hosts you will not get an IP

Improve this answer
2
  • thanks. So, does that mean if I just have an entry for my local host in the /etc/hosts file, and I block port 53 for TCP/UDP, I couldn't access the internet at all?
    – Ramesh
    Dec 10, 2014 at 4:02
  • 5
    you can access the internet just fine.. you just can't resolve hostname to ip unless you add an entry for every host you want to visit in /etc/hosts
    – Mike
    Dec 10, 2014 at 4:04
3

So my question is if I block all the outbound traffic of port 53 in my machine using the firewall rules, does that mean I couldn't resolve any host name at all?

Well, your operating system has more than likely built up a cache of previous DNS query responses, but those will expire and once they do you will have no ability to resolve domain names at all, that is basically correct.

Complicating matters somewhat is that you can "hard-code" some domain→IP mappings in a file (/etc/hosts), and that there are other ways to resolve domain names — various local network domain controllers, for example (which may not use DNS and, if not, probably don't use port 53). However, those are not likely to help you get onto Facebook.

Improve this answer
2

HTTP clients ordinarily use DNS forward queries when make connections, but not necessarily, because such thing as HTTP proxy is possible. It delegates resolving server name to the proxy (that can, in turn, query another proxy. etc.). Ī once read (although didn’t see) that ancient LAN protocols allowed browsers to operate without TCP at all.

Moreover, if an application calls gethostbyname() or similar, then it might result in an outbound packet, but not necessarily, because it is a question of DNS implementation in particular operating system and its setup. One of situations where gethostbyname() doesn’t result in an outbound traffic is locally-operated (127.0.0.1) DNS server that, for some reason, already cached all DNS records required.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .