研究室で DNS ゾーン更新時の外からの確認方法について質問されたので書いておきます．n 番煎じですがこのサイトも久々に動かしたかったので．たいして DNS に詳しいわけでもないので間違ってたら言ってください．Twitter でたくさんまさかり投げられそう．
なお，ここでは確認方法だけを取り扱い，ミスを確認後の修正すべき点については out of scope とさせていただきます．また，技術的厳密性は怪文書並みです．
外から確認するときと権威サーバ内部から必要な権限をもって確認するときのふたとおりをかきます．なお，委譲設定の変更でゾーンファイルを書き換えたときなどは当然これだけでは不十分で，DNS の木構造に沿って確認する必要などがあります．
まず外から確認するときは，このコマンドを実行します．
dig {RR_type} {RR_name} @{auth_addr} +norec
各パラメータは以下のとおりです．
RR_type: 確認したいレコードのレコードタイプ (AAAA, MX など)
RR_name: 確認したいレコードのレコード名 (FQDN など)
auth_addr: 当該レコードを返すべき権威サーバの IP アドレス (not FQDN)
※ 当該レコードを返すべき権威サーバが複数ある場合，全てに対してこの確認を行います．
例えば，「wiki.jj1lfc.dev. の AAAA レコードを 2001:19f0:7002:790:5400:2ff:fe7d:6b14 に書き換えたんだけど，正しくこれでひけるか確認したい」というときはこうです (jj1lfc.dev.ゾーンの権威サーバは ns{1,2}.jj1lfc.dev. で，それぞれの IP アドレスは 2400:6180:0:d1::776:1001, 2401:c080:1000:4c9f:5400:3ff:fe2f:a3b とします)．
dig AAAA wiki.jj1lfc.dev. @2400:6180:0:d1::776:1001 +norec
dig AAAA wiki.jj1lfc.dev. @2401:c080:1000:4c9f:5400:3ff:fe2f:a3b +norec
このときの結果として期待されるのは，例えばこのようなものです．
; <<>> DiG 9.16.1-Ubuntu <<>> AAAA wiki.jj1lfc.dev. @2400:6180:0:d1::776:1001 +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12256
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;wiki.jj1lfc.dev. IN AAAA
;; ANSWER SECTION:
wiki.jj1lfc.dev. 3600 IN AAAA 2001:19f0:7002:790:5400:2ff:fe7d:6b14
;; Query time: 95 msec
;; SERVER: 2400:6180:0:d1::776:1001#53(2400:6180:0:d1::776:1001)
;; WHEN: Mon Feb 08 22:49:28 JST 2021
;; MSG SIZE rcvd: 72
このとき確認すべきは，主に以下の項目です．
NOERROR となっており，answer section が存在していること (NOERROR レスポンス)．NOERROR となっており，ANSWER SECTION が存在していないこと (NODATA レスポンス)．NXDOMAIN となっていること (NXDOMAIN レスポンス)．また，ゾーン転送を行っている場合は当該ゾーンの SOA レコードを問い合わせてゾーンシリアルのアップデートを確認することも有効です．
例えば:
dig SOA jj1lfc.dev. @2400:6180:0:d1::776:1001 +norec +short
答えとしては:
ns1.jj1lfc.dev. dnsadm.m.jj1lfc.dev. 1612482141 600 600 259200 300
全部フルフルできいて回った結果を貼ると長いので +short しましたが，この例では 1612482141 がゾーンシリアルです．
プライマリ権威サーバ，セカンダリ権威サーバにそれぞれ問い合わせて，シリアルがアップデートされていること，みんな同じシリアルになっていることを確認します．
ゾーン転送を受けているセカンダリ権威サーバは，ゾーンシリアルが以前と比較して増えている場合のみ，ゾーン転送を受け入れます．これができていないと，きいた権威サーバによって正しい答えが帰ってこないロシアンルーレット状態になります．
ssh などで適切な権限をもって権威サーバのシェルをいじれるときは，権威サーバ内で上記と同様のことをやることもできます．特に中からはゾーンファイルが本当に書き換わっているのかどうかと，ログファイルを以下の項目について確認します．
フルサービスリゾルバやプロキシに聞いてしまっている場合が多いと思います．キャッシュを持つリゾルバの場合 (多くのフルサービスリゾルバがそうですが)，ゾーン更新前にすでにキャッシュされていた場合はキャッシュから返答しますので，当然アップデートされた内容は確認できません．
@localhost できいている権威サーバは localhost について listen しているとは限りません．また，後世にもよりますが，実際に DNS クエリを投げてくる人たちは localhost からはクエリしてきません．権威サーバ内からクエリする場合でも必ず NS として登録しているホストの IP アドレスに対してクエリします．
状況によっては権威サーバ自体の名前解決が期待した結果にならないことがあります．これは別の障害なので別の対処をする必要がありますが，ゾーンの更新について検証できていません．
権威サーバが，設定が読めていないなどで中途半端に死んでいることが往々にしてあるので，その際に気づけないかもしれません．ゾーンが更新されていないことは別の異常と関連していることも?
rd フラグの有無をちゃんと読んでいないと，リゾルバ共存権威サーバなど悪い運用にあたっているときにミスリードします (そもそもそんなサーバ捨てちまえ)．
aa フラグの有無をちゃんと読んでいないと，設定異常やゾーン転送異常のときの原因推定をミスります．
あたりまえのことですが，ANSWER SECTION を読まないとわかりません．間違ってリゾルバにきいてしまっているケースは，TTL で気付ける場合もあります．
意図したサーバにクエリを投げて帰ってきているのかを確認しないと，実はうまく動いているのに動いていないと勘違いしてアタフタすることがあります (僕だけ?)．
もう面倒なので詳細は省きます．
別の管理者が直前に不適切なゾーン編集をしたがちゃんと確認しなかったため，自分がどれだけ正しくゾーン編集しても全然正しく動かないという状況に出くわしたことがあります．毎回の確認で防げます．
以上，「最低限」と言うにはすこし多いかもしれない確認項目でした．足りないことはないと信じてる．