Thursday, May 27, 2010

How Deadwood will do glueless NS referrals

“Glueless NS referrals” is when a DNS servers gives us the name, but not the IP, of a given DNS server which is “closer” to the answer we seek.

In order to handle glueless NS referrals, we will have to perform some recursion to resolve them. Since Deadwood uses the select() model, the recursion has to be handled by hand. In addition, since we do multiple in-flight merging, things are a little more complicated.

Here is my current plan:
  • We will add three numbers to each outgoing recursive request: recursion_depth (int; can be 16-bit or bigger), parent_id (int 16-bit or bigger), and chain_id (32-bit)
  • recursion_depth is how many times we’ve followed a glueless NS record (or incomplete CNAME referral); if this exceeds 32, we stop.
  • parent_id is the ID of the request that needs to be solved before we can continue solving this DNS name. For example, if we ask for, and the .com DNS servers tell us, without giving us an IP, that the nameservers for are and (say), we hold the current request, and make the parent ID one solving Called “parent_id” because multiple recursion attempts might be trying to solve the same name at the same time, but a given recursion attempt only has a single parent_id
  • chain_id This is a unique 32-bit number. When we spawn a “parent” request, we first make sure there isn’t a request already in-flight which would cause a loop. This is done because, when spawning a “parent”, the parent has the chain_id as the “child” request; if we find a request already in-flight with the same chain_id, we consider it a loop and give up.
Glueless NS referrals will be a little complicated to implement with Deadwood, but this is the last major hurdle before we have full recursion (we will also use the same code to handle incomplete CNAME referrals).