dig example.com -t ns
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @4.2.2.1 example.com -t ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47717
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;example.com. IN NS
;; ANSWER SECTION:
example.com. 7200 IN NS b.iana-servers.net.
example.com. 7200 IN NS a.iana-servers.net.
;; Query time: 28 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Thu Mar 13 11:30:11 2014
;; MSG SIZE rcvd: 121
Since SPF are just a regular TXT records, lookup all TXT records and grep for SPF
dig gmail.com -t TXT | grep spf
gmail.com. 290 IN TXT "v=spf1 redirect=_spf.google.com"
Here, their SPF is an alias for another entry, so you'll need to query that also to get the actual values.
dig _spf.google.com -t TXT | grep spf
; <<>> DiG 9.4.2-P2 <<>> _spf.google.com -t TXT
;_spf.google.com. IN TXT
_spf.google.com. 300 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
Since there're even more - you'll have to keep digging down to find the actual IPs.
Say you'd like to find out the authority for PTR records for the 8.10.97.0/24 subnet:
dig 0.97.10.8.in-addr.arpa. -t ns
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @ns2.level3.net. 0.97.10.8.in-addr.arpa. -t ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29359
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;0.97.10.8.in-addr.arpa. IN NS
;; AUTHORITY SECTION:
10.8.in-addr.arpa. 3600 IN SOA ns2.Level3.net. dns.Level3.net. 2013110801 7200 600 2592000 3600
;; Query time: 25 msec
;; SERVER: 209.244.0.2#53(209.244.0.2)
;; WHEN: Thu Mar 13 16:53:15 2014
;; MSG SIZE rcvd: 947.
It is also often "worth it" to query a PTR within a subnet - as some ISPs keep the .0/.1 addresses to themselves for gateways. That is the case with 8.10.97.0; as if we query 8.10.97.5 we get different results:
dig 5.97.10.8.in-addr.arpa.
; <<>> DiG 9.4.2-P2 <<>> 5.97.10.8.in-addr.arpa.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64468
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;5.97.10.8.in-addr.arpa. IN A
;; ANSWER SECTION:
5.97.10.8.in-addr.arpa. 3600 IN CNAME 5.2-255.97.10.8.in-addr.arpa.
;; AUTHORITY SECTION:
2-255.97.10.8.in-addr.arpa. 14400 IN SOA dnsdelta.intellifuel.net. noc.intellifuel.com. 2015072701 3600 1800 2419200 14400
;; Query time: 209 msec
;; SERVER: 209.18.47.61#53(209.18.47.61)
;; WHEN: Thu Sep 17 10:02:02 2015
;; MSG SIZE rcvd: 141
If/when you find that a particular address is not being controlled by the expected/desired nameserver as Authoritative, simple remove one-level (farthest left - so on 5.97.10.8.in-addr.arpa. remove "5." and look-up 97.10.8.in-addr.arpa., then remove "97." and re-look-up) at a time and keep querying.
To verify that your zones are configured to allow (or disallow) tranfers, test with dig/host:
host -t AXFR full.zone.example.com. dnsserver
dig @dnsserver full.zone.example.com. -t AXFR
host -t IXFR=SERIALHERE full.zone.example.com. dnsserver
dig @dnsserver full.zone.example.com. -t IXFR=SERIALHERE