Re: Simple DNS Record A

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On Tue, Jul 26, 2011 at 11:23:06AM +0100, ?ireann Leverett wrote:
> Hello all,
> 
> I'm looking into DNS resolution in Mirage, and learning OCAML at the same
> time. So forgive me if I'm a bit slow finding my way around in the code
> base.
> 
> I (like most people) have the 'magic version' of dns in my head, where I
> ask for a record and get a reply. Time to change that!
> 
> So to get started here's my model of an iterative DNS A record request:
> 
> localhost sends a udp request on port 53 to <IP of Nameserver>
> Then one of two things happens:
> 1) localhost gets a response on port 53 from <IP of Nameserver>
> with: IP address/s | not found
> 2) Timeout

Almost right. You're describing a 'recursive resolver', since it takes a 
client request, does the full resolution, and returns back the response.

An iterative resolver, on the other hand, would only point to the next
server in the DNS chain and return just that next result.  So a recursive
resolver is what responds to a typical client request, by performing
iterative resolution itself (or pointing to yet another resolver).

Here's a way to get familiar with this concept, using the 'dig' tool:

First, determine the root DNS servers on the Internet by:

$ dig 

This will return all the root name servers as NS records. These point to
the top-level domains such as org and com.

$ dig +norecurse @a.root-servers.net dark.recoil.org

At this point, do an iterative request to the root name server asking for
'dark.recoil.org'. It will not give an immediate reply, but will instead
point to the next name server for .org

You can continue this exercise by then requesting the .org name server:

$ dig +norecurse @a0.org.afilias-nst.info dark.recoil.org

...and so on until you get the IP address for dark.recoil.org

The recursive resolver for clients will perform this iteration process
itself, and possibly caching results (depending on the TTL for responses).

> 
> So a basic resolver needs a timeout, a nameserver (initially hardcoded, but
> later from configuration), and to be able to build the structure of the
> request and parse the response structure. I'm looking at the
> bitstring-v-native code for inspiration, here and functions I can use.
> 
> If this is the model for the A record then I'll flesh this into more
> meaningful pseudo code.

Yeah, keep fleshing it out and take notes on precisely what the process
is. Also see: 
http://www.umlgraph.org/doc/dns.html
For a message sequence chart of the various queries from a system level.

-- 
Anil Madhavapeddy                                 http://anil.recoil.org