I was wrong.
I can understand why DJB took some shortcuts with CNAME records in DJBdns. CNAME handling is pretty much the last thing I’m adding support for in Deadwood, MaraDNS 2.0’s recursive resolver. It’s like I have been running a 40 kilometer marathon and I’m within 50 meters of the finish line. I just want to run as fast as possible to the finish line and end the marathon.
So, yeah, I’m making some shortcuts with CNAME referrals. DJB has it so that CNAME records are not stored at all in the cache. Deadwood right now stores CNAME records in the cache, but only when the CNAME record is completed. For example, if I ask for up.nytimes.com, which is right now an incomplete CNAME record that points to up.about.akadns.net, Deadwood stores the completed version of up.nytimes.com with the IP for up.about.akadns.net in the entry for up.nytimes.com, but only when we get all of the information.
In addition, the CNAME records before the final answer (up.nytimes.com in the above example) have a fixed TTL of 60 seconds (which doesn’t mean anything); the final answer has a fixed TTL of 3600 seconds (one hour).
Right now, incomplete CNAME records only work if the record the incomplete CNAME points to is already in the cache. Resolving this is hopefully easier than getting CNAME records already in the cache working was; I think I have mostly done this when I got glueless NS referrals to work.
Another thing: If the resolution of an incomplete CNAME record is needed to handle a glueless record, the resolved record will not be used to help solve the parent query that needed the glueless record until that query is sent to Deadwood again. I may or may not fix this before releasing MaraDNS 2.0.
OK, back to finishing up incomplete CNAME referral support. I will hopefully have Deadwood 2.6.04 out in a few days.
