looking for reference to correct behavior

[Kevin Darcy]

It doesn't really matter whether the vendor claims that the data is 
"also" cached data, since the RFC clearly states "if the desired data is 
present in authoritative form [...] use the authoritative data in 
preference to cached data". In other words, authoritative data trumps 
cached data. This would apply even if one were to view the authoritative 
data as "also" being cached data.

RFC 2181 clarified this even further, by assigning "trustworthiness" 
levels to different kinds of data, with "Data from a primary zone file, 
other than glue data" and "data from a zone transfer, other than glue" 
being the two most trustworthy, and "non-authoritative data from the 
answer section of authoritative answers", being a few levels of 
"trustworthiness" lower than either of those. (When one or more CNAMEs 
are present in the Answer Section, only the CNAME matching QNAME is 
authoritative, everything else is non-authoritative, so this category 
matches your situation as described). Less-trustworthy data is never 
supposed to overwrite/override more-trustworthy data.

It's quite obvious that the vendor is not in compliance with the RFCs 
here, the main challenge is to pierce their obfuscations enough to make 
this plain to the Powers That Be.

- Kevin

Maria Iano wrote:
> By saying things like "We load the authoritative data into memory so 
> that is also cached data" and other nonsense the vendor is stating 
> that this behavior is in compliance with the RFCs and refusing to fix 
> their code. Very frustrating, as I believe this behavior is clearly 
> wrong and also seems to me to be a security issue.
>
> Thanks for your help anyway!
> Maria
>
> On May 11, 2009, at 2:33 PM, Kevin Darcy wrote:
>
>> The "resolver algorithm" in RFC 1034, Section 5.3.3, states
>>
>> 1. See if the answer is in local information, and if so return
>>
>> it to the client.
>>
>>
>> and is further detailed as
>>
>> Step 1 searches the cache for the desired data. If the data is in the
>> cache, it is assumed to be good enough for normal use. Some resolvers
>> have an option at the user interface which will force the resolver to
>> ignore the cached data and consult with an authoritative server. This
>> is not recommended as the default. If the resolver has direct access to
>> a name server's zones, it should check to see if the desired data is
>> present in authoritative form, and if so, use the authoritative data in
>> preference to cached data.
>>
>> This would be a case where the resolver "has direct access to the 
>> name server's zones", so there is no debate, in my opinion, that the 
>> resolver in question is doing The Wrong Thing.
>>
>> RFC 2181 also makes it clear that authoritative data ranks higher 
>> than cached data, so that could also be used as a relevant normative 
>> reference.
>>
>> - Kevin
>>
>> Maria Iano wrote:
>>> My apologies if this is considered to be too off-topic.
>>>
>>> I have a situation where my company uses a number of servers with a 
>>> commercial DNS implementation (in addition to our BIND servers). The 
>>> other implementation is Windows DNS, and there is some behavior that 
>>> I do not think is acceptable, but which the vendor claims is 
>>> acceptable behavior. I really want them to fix this bug (as I 
>>> consider it), but first I need to get general agreement that it is a 
>>> bug. I will be looking through the RFCs as much as I can time for, 
>>> but haven't found what I need yet. Since my next meeting with the 
>>> vendor is tomorrow, I thought I would also ask if anyone can already 
>>> point me to a relevant RFC or other reference.
>>>
>>> Here is the behavior that I think is not acceptable.
>>>
>>> We have configured a zone on the windows server - dmz.example.com. 
>>> This zone contains an A record for foo.dmz.example.com with IP 
>>> address 10.240.240.240. The zone example.com is hosted elsewhere and 
>>> contains a CNAME record foo.example.com pointing to 
>>> foo.dmz.example.com.
>>>
>>> If the cache has just been cleared, and a client asks the WIndows 
>>> DNS server for foo.example.com, it has a forwarding server to which 
>>> it forwards the request. The forwarding server hands it back the 
>>> CNAME record but it also hands back an A record for 
>>> foo.dmz.example.com pointing to an incorrect IP address 
>>> 192.168.240.240. The Windows DNS server accepts this A record for 
>>> foo.dmz.example.com with an incorrect IP address into its cache, and 
>>> hands out that incorrect information to the client. Even though it 
>>> concurrently has dmz.gannett.com configured on it as a primary zone 
>>> with a record for that same owner name pointing to a different IP 
>>> address.
>>>
>>> I believe it shouldn't do that. Since it hosts dmz.example.com as a 
>>> primary zone, I think it should discard that bad A record and hand 
>>> back its own.
>>>
>>> The vendor's argument is that it should blindly trust the forwarding 
>>> resolver.
>>>
>>> Can anyone point me to an RFC or reference about this?
>>>
>>> Thanks,
>>> Maria
>
>