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