Support this website
I discuss the OnceTV update from the other day and some possible consequences of the code change I did.

==Note on updating Deadwood==

When updating Deadwood to fix the oncetv-ipn.net bug, be sure to delete Deadwood’s cache:

• Stop Deadwood
• Remove the cache file
• Start Deadwood again

Otherwise, Deadwood will have bad NS referrals in its cache.

==The speed up==

Let’s suppose we have the following gluless name referral to follow to resolve name.example.net:

• First we go the the root name servers
• Which point us to the .net servers, who point out the nameservers for name.example.net are ns1.example.org and ns2.example.org:

AN
<blank>

NS
example.net NS ns1.example.org
example.net NS ns2.example.org

AR
<blank>

• We now go back to the root name severs
• Which take us to the .org name server who give us this packet:

AN
<blank>

NS
example.org NS ns1.example.org
example.org NS ns2.example.org

AR
ns1.example.org A 172.31.254.1
ns2.example.org A 172.31.254.2

Now, with versions of Deadwood before the oncetv-ipn.net update, we would now go to one of the example.org name servers before getting our final answer; the oncetv-ipn.net update saves us a single DNS query by resolving the glueless record when querying the .org name servers.

In most cases, when resolving glueless name server records, this saves us one DNS lookup.

One minor disadvantage is that if we want to find another record in example.org, Deadwood and have cached all the records needed to solve name.example.net, Deadwood will now have to do two instead of one lookup (since earlier versions of Deadwood would cache the nameservers for example.org, but current Deadwood will instead cache the IP for either ns1.example.org or ns2.example.org).

==A new corner case==

Let us suppose we are looking for ns01.example.org and the upstream DNS server gives us this record:

AN
<blank>

NS
example.org NS ns1.example.org

AR
ns1.example.org A 172.31.254.1
ns1.example.org A 172.31.254.2

The updated Deadwood, when getting this packet, will assume ns1.example.org only has one IP, 172.31.254.1 in this case since that was the first IP in the packet Deadwood got. Should 172.31.254.2 be the only server that can resolve example.net (and lists ns1.example.org as its glueless name server), Deadwood would now be unable to resolve example.net.

Should I see a real-world case where this particular corner case causes a domain to be unable to resolve, I will update Deadwood to handle it. At this point I only update Deadwood to solve real-world domain resolution issues (as well as security issues); theoretical problems are put on the back burner.

==Deadwood roadmap==

I plan on releasing Deadwood 3.2.04 soon; at this point, 3.2.03e would only be released should I discover another security issue. 3.2.04 will first be a testing release; I will mark it as being a stable release after seeing no problems caused by it for a couple of months.

To post a comment about this blog entry, go to the forum (self-signed https). New accounts may post once I approve the account.