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