looking for reference to correct behavior

Kevin Darcy kcd at chrysler.com
Mon May 11 18:33:21 UTC 2009


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
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>




More information about the bind-users mailing list