In order for the changes to be propagated, the serial in the zone file needs to be updated. Quoting the documentation:
The <serial-number> directive is a numerical value incremented every time the
zone file is altered to indicate it is time for named to reload the zone.
So as your comment says, you forgot this step -- so the zone file was not loaded by the primary DNS server, and never made it anywhere. So I wonder what "Google picked up" -- but to solve your issue, increment the serial number in your zone file. If I may suggest: For my zone files' serials, I use the pattern YYYYMMDDNNN (i.e. 4-digit year followed by 2-digit month plus 2-digit day, and 3-digits for the "change number of the day" -- unlikely to have more than 999 changes a day), e.g. for the first change today 20120706001. This is a valid serial, and you always can see the time of the latest change easily as well as increment it easily.
Having increased the serial, the DNS server should reload the zone file and propagate changes automatically.
dig +trace works by pretending it's a name server and works down the namespace tree using iterative queries starting at the root of the tree, following referrals along the way.
The first thing it does is ask the normal system DNS server for NS records for "."
After it gets a response, which will be the current list of root name servers, it'll pick one and then ask for the A record for that name if it didn't get it in the additional records section the first time so it's got an IP address to send the next query to. Let's say it picks f.root-servers.net whose IP address is 192.5.5.241.
At this point, let's use dig +trace www.google.co.uk. as our command with a domain name we want to trace the resolution path for.
The next behind-the-scenes query will be this:
$ dig +norecurse @192.5.5.241 www.google.co.uk
; <<>> DiG 9.9.4 <<>> +norecurse @192.5.5.241 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8962
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 15
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; AUTHORITY SECTION:
uk. 172800 IN NS ns5.nic.uk.
uk. 172800 IN NS ns6.nic.uk.
uk. 172800 IN NS ns4.nic.uk.
uk. 172800 IN NS nsc.nic.uk.
uk. 172800 IN NS ns2.nic.uk.
uk. 172800 IN NS ns3.nic.uk.
uk. 172800 IN NS nsd.nic.uk.
uk. 172800 IN NS nsa.nic.uk.
uk. 172800 IN NS ns7.nic.uk.
uk. 172800 IN NS nsb.nic.uk.
uk. 172800 IN NS ns1.nic.uk.
;; ADDITIONAL SECTION:
ns1.nic.uk. 172800 IN A 195.66.240.130
ns2.nic.uk. 172800 IN A 217.79.164.131
ns3.nic.uk. 172800 IN A 213.219.13.131
ns4.nic.uk. 172800 IN A 194.83.244.131
ns5.nic.uk. 172800 IN A 213.246.167.131
ns6.nic.uk. 172800 IN A 213.248.254.130
ns7.nic.uk. 172800 IN A 212.121.40.130
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
nsc.nic.uk. 172800 IN A 156.154.102.3
nsd.nic.uk. 172800 IN A 156.154.103.3
ns1.nic.uk. 172800 IN AAAA 2a01:40:1001:35::2
ns4.nic.uk. 172800 IN AAAA 2001:630:181:35::83
nsa.nic.uk. 172800 IN AAAA 2001:502:ad09::3
;; Query time: 45 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Tue Feb 11 19:19:14 MST 2014
;; MSG SIZE rcvd: 507
Wow, so now we know that there are nameservers for uk and that's the only thing the root server knows about. This is a referral, because we did not ask for recursion (+norecurse turns it off).
Great, we rinse and repeat. This time we pick one of the uk nameservers and ask it the same question.
$ dig +norecurse @195.66.240.130 www.google.co.uk
; <<>> DiG 9.9.4 <<>> +norecurse @195.66.240.130 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 618
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; AUTHORITY SECTION:
google.co.uk. 172800 IN NS ns1.google.com.
google.co.uk. 172800 IN NS ns3.google.com.
google.co.uk. 172800 IN NS ns2.google.com.
google.co.uk. 172800 IN NS ns4.google.com.
;; Query time: 354 msec
;; SERVER: 195.66.240.130#53(195.66.240.130)
;; WHEN: Tue Feb 11 19:22:47 MST 2014
;; MSG SIZE rcvd: 127
Awesome, now we have found out that the uk top-level nameserver knows there's a zone called google.co.uk and tells us to go ask those nameservers our question. This is another referral.
Rinse, repeat.
This time, however, we didn't get A records in the additional records section of the response, so we pick one, say ns2.google.com, and we have to go find it's address. We restart a query (at the root again) and chase down the tree to find the IP address for ns2.google.com. I'll skip that part for brevity, but we learn that the IP for it is 216.239.34.10.
So our next query is:
$ dig +norecurse @216.239.34.10 www.google.co.uk
; <<>> DiG 9.9.4 <<>> +norecurse @216.239.34.10 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33404
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; ANSWER SECTION:
www.google.co.uk. 300 IN A 74.125.225.216
www.google.co.uk. 300 IN A 74.125.225.223
www.google.co.uk. 300 IN A 74.125.225.215
;; Query time: 207 msec
;; SERVER: 216.239.34.10#53(216.239.34.10)
;; WHEN: Tue Feb 11 19:26:43 MST 2014
;; MSG SIZE rcvd: 82
And we're done! (finally) How do we know we're done? We got an answer to our query, which was the A records for www.google.co.uk. You can also tell because it's not a referral anymore, the aa bit is set in the last response meaning this is the authoritative answer for your query.
So that's what's happening each step along the way when you use dig +trace.
Note that if you have a DNSSEC-aware version of dig and you add +dnssec to the command, you may see a bunch more records. What those extra records are is left as an exercise for the reader... but gets into how dig +sigchase works.
Best Answer
as
digis a part ofbindpackage just install bind then you will be able to usedigon mac:-