Possible bug in Cache.addMessage

If the message given to Cache.addMessage has 4 answers like this:

appP3N1.TLD.	1	IN	CNAME	appP3N1.S.TLD.
appP3N1.S.TLD.	1	IN	CNAME	appP3N1.Q.TLD.
appP3N1.Q.TLD.	1	IN	CNAME	Qserver02_c0.TLD.
Qserver02_c0.TLD.	86400	IN	A	10.0.4.12

I would expect that the returned SetResponse should have the type SetResponse.SUCCESSFUL. However due to the response being created inside the if branch for CNAME record, the returned value has the type SetResponse.CNAME. This causes Lookup.processResponse to follow the CNAME records through the cache rather than just returning the value immediately.

I believe that the response object needs to be created from the last answer rather than the first answer.

[jschewebbn]

I’m referring to the initial query. As it stands right now, the query to the server is done, processResponse is returning a SetResponse with the type set to CNAME rather than SUCCESSFUL. This causes an unneeded search through the cache and the execution of the follow method.

[ibauersachs]

Return which response directly? The Message coming in from the resolver is not the same as what is returned from the cache. I had a look at the stuff yesterday and it’s too convoluted to change for, as Noa correctly states, nothing. The long CNAME chains you’re referring to are an anomaly, and nobdy in their right mind would create a longer than 5-6 CNAMEs. Given BINDs popularity, I don’t think you’d get many responses that even go beyond the hard limit of 16.

I’m going to close this issue. If you’re up for a pull request though, I’ll certainly have a look.