Looking at the IP addresses in your resolv.conf I get the feeling that your BIND server is on 192.168.1.52. As far as I can tell, you can't specify in resolv.conf something like "for these domains, use this name server". Basically, your BIND server will never be queried. As you can see in your dig lookup (which is incorrect, it is asking for a reverse DNS entry), it tries 80.58.0.33, which I assume is your provider's DNS server.
You already set up BIND as caching nameserver by using the 'forwarders' option, so what you need to do is have only 192.168.1.52 in the client PCs as nameserver.
To see if your BIND is configured correctly, try this:
dig example.test @192.168.1.52
Yes, the number there is the number of seconds left until that record expires (providing we're not querying the authoritative nameserver). Obviously with a CNAME there's a level of redirection, so the TTL for the A record it points to in this case may be important as well.
If you wait a couple of seconds and run dig again on your local nameserver, you should see that TTL number decrease by the number of seconds you waited (approximately). When it hits 0, it'll refresh or if your nameserver refreshes the zone for some reason.
As mentioned above, there is a difference between dig being run against a nameserver with a cached entry and the nameserver that is authoritative for that entry.
(in the examples I use below I use the +noauthority +noquestion & +nostats flags just to keep the output terse).
Note the difference between the following queries:
$ dig +noauthority +noquestion +nostats stackoverflow.com @ns2.p19.dynect.net.
; <<>> DiG 9.7.0-P1 <<>> +noauthority +noquestion +nostats stackoverflow.com @ns2.p19.dynect.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50066
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; ANSWER SECTION:
stackoverflow.com. 432000 IN A 69.59.196.211
So in the above query, we're querying a nameserver that is authoritative for stackoverflow.com. If you notice the flags section, pay special attention to the aa flag which denotes this is an authoritative answer (i.e. not cached).
$ dig +noauthority +noquestion +noadditional +nostats stackoverflow.com
; <<>> DiG 9.7.0-P1 <<>> +noauthority +noquestion +noadditional +nostats stackoverflow.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43514
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; ANSWER SECTION:
stackoverflow.com. 246696 IN A 69.59.196.211
In the above query, we don't have an aa flag, and the TTL will keep decreasing as we query and query. This is essentially the counter I was talking about previously.
Best Answer
There is no query based way to get server state. Glue, negative cache timers, etc. must be dumped from memory using the
rndc dumpdbcommand.\-are negatively cached.\-A,\-AAAA, etc.\-ANYindicates a trueNXDOMAIN. No records live alongside or beneath this entity.The above might be confusing if you have not been exposed to the concept of
NODATAbefore. (RFC 2308) It means an answer ofNOERRORwith 0 answers was seen, as opposed toNXDOMAIN.NXDOMAINindicates that no records with that name exist at all.Example negative cached entries:
Parsing this file automatically is not for the faint of heart, especially when the label name is omitted due to repetition.