To answer the original question. There isn't a flag for the query
or the client as answers are made up of data from multiple sources.
'is_zone' is set to ISC_TRUE or ISC_FALSE depend apon whether the
current db is a zone data base or not.
"aa" is only applicable to the first rrset in a DNAME/CNAME chain.
Mark
In message <4e2de4fc.1020...@chrysler.com>, Kevin Darcy writes:
> On 7/25/2011 6:14 AM, harish badrinath wrote:
> > (Originally sent to bind-workers, sorry if this is considered cross
> > posting. Slightly modified from the original message)
> >
> > Hello,
> >
> > I am using Bind version:BIND 9.7.1-P2
> >
> >
> > I am doing some small internal changes to bind and i have to know when
> > a query is being answered from internal cache and when from resolvers.
> >
> > That information doesn=92t seem to be recorded in client.attributes or
> > client->query.attributes ??
> >
> > Can any one tell me where the code branches for cached/non cached
> > responses in function query_find in the file "bin/named/query.c" *or*
> > if the current client was responsible for cache insertion/addition for
> > client->query.qname.
> >
> > I need help, to generate a construct along the lines of,
> > if(condition|binary_function =3D=3D (true|false))
> > {
> > response was given by cache
> > }
> >
> > *or*
> > #define ISFROMCACHE(client/query) ...
> >
> Whatever you're trying to accomplish, it's would not appear to be =
>
> consistent with the founding RFCs for DNS:
>
> (RFC 1034, Section 5.3.3, Resolver Algorithm):
>
> "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 [capitalization =
>
> added - kcd]. 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."
>
> Perhaps it would help if you explained *why* you care whether the data =
>
> is from cache or not (?) If you're concerned about the *integrity* of =
>
> the DNS data, you should do some research on DNSSEC.If you have a =
>
> different reason, maybe there's a better way to accomplish your goal.
>
> =
>
> =
>
> - Kevin
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscri=
> be from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
