2016年9月28日水曜日

BIND9(named)をsupervisordで管理する

CVE-2016-2776対応されているみなさま、お疲れさまです。一緒に頑張りましょう。

今回の脆弱性はかなり簡単にプロセスをダウンさせられるようなので、
自動復旧させるためにCentOS6上でsupervisorで管理してみます。

外部からの監視ベースだと監視間隔が1~5分程度あると思いますので、
ダウン発生から検知復旧に間が空いてしまいます。
その場しのぎではありますが、ダウンタイムの最小化の一案として試してみます。

(CentOS7系はsystemdで同様の管理ができるのでsystemdで行えば良いでしょう。
また、daemontools派の方も同様の事ができると思います。
商用のコントロールパネルにも自己監視機能があったと思います。)

以下、実手順です。

参考: Men and Miceのサイト

・インストール

EPELレポジトリから導入できます。

# yum install supervisor
読み込んだプラグイン:product-id, security
インストール処理の設定をしています
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> Package supervisor.noarch 0:2.1-9.el6 will be インストール
--> 依存性の処理をしています: python-meld3 のパッケージ: supervisor-2.1-9.el6.noarch
--> トランザクションの確認を実行しています。
---> Package python-meld3.x86_64 0:0.6.7-1.el6 will be インストール
--> 依存性解決を終了しました。

依存性を解決しました

========================================================================================================================
パッケージ アーキテクチャ バージョン リポジトリー 容量
========================================================================================================================
インストールしています:
supervisor noarch 2.1-9.el6 epel 292 k
依存性関連でのインストールをします。:
python-meld3 x86_64 0.6.7-1.el6 epel 71 k

トランザクションの要約
========================================================================================================================
インストール 2 パッケージ

総ダウンロード容量: 364 k
インストール済み容量: 1.4 M
これでいいですか? [y/N]y
パッケージをダウンロードしています:
(1/2): python-meld3-0.6.7-1.el6.x86_64.rpm | 71 kB 00:00
(2/2): supervisor-2.1-9.el6.noarch.rpm | 292 kB 00:00
------------------------------------------------------------------------------------------------------------------------
合計 8.0 MB/s | 364 kB 00:00
rpm_check_debug を実行しています
トランザクションのテストを実行しています
トランザクションのテストを成功しました
トランザクションを実行しています
インストールしています : python-meld3-0.6.7-1.el6.x86_64 1/2
インストールしています : supervisor-2.1-9.el6.noarch 2/2
Verifying : python-meld3-0.6.7-1.el6.x86_64 1/2
Verifying : supervisor-2.1-9.el6.noarch 2/2

インストール:
supervisor.noarch 0:2.1-9.el6

依存性関連をインストールしました:
python-meld3.x86_64 0:0.6.7-1.el6

完了しました!

・設定

/etc/supervisord.confに、先のMen&Miceのサイトの例の以下部分を追記します。
[program:named]
command=/usr/sbin/named -u named -f
process_name=%(program_name)s
numprocs=1
directory=/var/named
priority=100
autostart=true
;autorestart=unexpected
autorestart=true
startsecs=5
startretries=3
exitcodes=0,2
stopsignal=TERM
stopwaitsecs=10
redirect_stderr=false
stdout_logfile=/var/log/named_supervisord.log
stdout_logfile_maxbytes=1MB
stdout_logfile_backups=10
stdout_capture_maxbytes=1MB

(autorestart=unexpectedがエラーになったので一旦trueにしています)

・起動

# ps -ef | grep named
root 6991 6321 0 20:08 pts/0 00:00:00 grep named
# service supervisord start
supervisord を起動中: [ OK ]
# ps -ef | grep named
named 7004 7002 0 20:08 ? 00:00:00 /usr/sbin/named -u named -f
root 7011 6321 0 20:08 pts/0 00:00:00 grep named
supervisordを起動することでnamedも上がってきました。

・確認&障害復旧テスト

プロセスを強制終了して疑似障害を起こしてみます。
# supervisorctl status
named RUNNING pid 7004, uptime 0:00:09
# kill -KILL 7004
# supervisorctl status
named STARTING
# ps -ef | grep named
named 7013 7002 0 20:08 ? 00:00:00 /usr/sbin/named -u named -f
root 7020 6321 0 20:09 pts/0 00:00:00 grep named
# supervisorctl status
named RUNNING pid 7013, uptime 0:00:11

プロセス強制終了後、すぐにsupervisordによって検知&再起動が行われ、新たなプロセスIDで起動しています。

・停止

# service supervisord stop
supervisord を停止中: [ OK ]
# ps -ef | grep named
root 7051 6321 0 20:09 pts/0 00:00:00 grep named

2016年8月21日日曜日

Y:A:D::I::F:A 2.2のマルチマスター機能をお試し


YADIFA 2.2がリリースされました(発表)。
その中で、権威スレーブサーバーとしての新機能「マルチマスター対応」が実装されたとのことなので さっそく試してみました。

環境構成

検証環境は上記図の通りです。せっかくなので触ってみたいソフトウェアをいろいろ詰め込んでみました。
  • 権威マスター: BIND 9.10.4-P2とPowerDNS 4.0.0-1p
  • 権威スレーブ: YADIFA 2.2.1
  • 再帰検索DNS: Knot Resolver 1.1.0
権威マスター2台の間は、ひとまず特に同期システム無しで手動入力です。

YADIFAの設定

yadifad.confを作成します。以下抜粋にて

<main>
queries-log-type 3
</main>
<zone>
        domain          yadtest.w4yh.jp
        file            slaves/yadtest.w4yh.jp.zone
        type            slave
        masters         133.18.nn.nn,153.127.nn.nn
        multimaster-retries 2
        true-multimaster false
</zone>

 

mastersの指定部分でカンマ区切りで複数のIPアドレスを列挙することでマルチマスター設定になります。
書いた順番に優先となり、最初に書いたIPアドレスのサーバーが通常のマスターとして参照します。

動作検証


1つめのmaster(133.18.nn.nn, PowerDNS)を落としてみます。(以下、引用部分はyadifaのログを示します)
| server | E | slave: query error for domain yadtest.w4yh.jp. from master at 133.18.nn.nn#53: Connection refused
今回はmultimaster-retries 2で設定しているので、最初の1回 + リトライ2回 = 3回エラーが続くと切り替わります。
| server | W | slave: 133.18.yadtest#53 master failed to answer for domain yadtest.w4yh.jp.: next master is 153.127.nn.nn#53

通常あまりないと思いますが、マスターを切り替えた結果ゾーンが更新されていた場合には、切り替えた2つ目のマスターサーバーからのゾーン転送が行われます。
| I | slave: loaded IXFR for domain yadtest.w4yh.jp. from master at 153.127.nn.nn#53, new serial is 2016081401

true-multimaster


次に、true-multimasterをtrueにします。 これは「マスターの切り替えが発生した場合には、現在のゾーン情報を破棄して切り替わり先の新しいマスターから取得しなおす」という動作を指定する設定です。前の恋人との思い出は全部捨てて新しい恋に生きます、みたいな感じ?
まず優先マスターからゾーン転送を受けておきます。
| I | slave: loaded AXFR for domain yadtest.w4yh.jp. from master at 133.18.nn.nn#53, serial is 2016081401
この後マスターを落とすのは同じくですが、切り替わり先に敢えて古いシリアルのゾーンを入れておきます。 その結果、
| W | slave: 133.18.nn.nn#53 master failed to answer for domain yadtest.w4yh.jp.: next true master is 153.127.nn.nn#53
| D | slave: deleting '/opt/yadifa/var/zones/slaves/yadtest.w4yh.jp.zone'
| D | slave: deleting '/opt/yadifa/var/zones/xfr//98/3e/yadtest.w4yh.jp..axfr'
| D | database: yadtest.w4yh.jp.: will enqueue operation DATABASE_SERVICE_QUERY_AXFR at 2016-MM-DD hh.mm.dd (10分後)
| I | slave: loaded AXFR for domain yadtest.w4yh.jp. from master at 153.127.nn.nn#53, serial is 2016080101
| I | database: yadtest.w4yh.jp.: zone successfully downloaded (AXFR)
シリアル番号は下がりますが、切り替わり先のマスターからゾーンファイルを上書き受信できました。
ちょっと意外だったのは、最初のマスターがダウンしたと判定された時点でゾーンファイルの削除が行われ、約10分間ファイルの無い状態が発生したことです。
ロードはされているのでDNSクエリへの応答はあったのですが(ダンプは見ていないので詳細は要確認)、一時的にファイルを失うというのは監視の仕方によっては厄介かもしれません。

どこで使う?


設定のmastersに並べるだけで冗長化できるという便利な設定を確認できました。この使いどころはどういうケースなのでしょうか。
masterが異なるIPアドレスで冗長されている、ということでVirtual IP addressを持った冗長を組んでいるところでは不要です。
internalセグメントにActive DirectoryのDNSが何台かいて、DMZのyadifaがslaveとして受け取る、というような場合は使えそうです。
また、yadifaの開発元であるEURidはドメイン提供~メール&ウェブ環境の提供の一括管理をしているので、ドメイン情報は業務システムのデータベースに入っていて、そこから負荷や可用性レベルを切り離した複数のマスターサーバーがhidden(ステルス)で稼動しているのかもしれません。
WHD.glocal 2014での発表資料

余談


今回の検証環境は日割りで初期費用無しで安く利用できる国内事業者さんを探して、Kagoya VPSを利用しました。個人で検証用にいい環境が他にもあれば情報いただきたいです。
せっかく一式の環境を作ったので、DNSおよびその監視についてもうちょっと検証を行う予定です。お題などありましたらツイッターコメントやTXTレコードでお知らせいただければ、余裕あればやってみます。

2016年7月12日火曜日

DNS Summer Day 2016に行ってきました

2016年6月24日、秋葉原UDX Conferenceにて開催されたDNS Summer Day 2016に参加しました。
3人掛けの席に3人+両サイドに補助席の大盛況でした。最前列前に地べた、とか治安悪くはならなかったのはWeb系との文化の違い?
Web系よりはるかに、運用系よりも少々、JANOGと同じくらい、高めの年齢層という感じでした。
DNSOpsのサイトにて各公演資料も公開されているので、
質疑応答や感想を中心にまとめておきます。

本イベントでは海外のテック系イベントやJANOGで見られるような、 「言いたいことある人はスタンドマイクのとこに並べ」形式を取っていたので 感想コメントも多く聞かれる特徴があります。

◎午前の部「BINDからの卒業」

今年はこれが聞きたくて参加しました。
ひと月前に行われた、JANOG US Regional Meeting #2の神明さんのBIND9に関する発表も見て万全での参加です。
内容もさることながら、みなさんはどのくらい卒業済みでどこに進級したのかなぁ、と。
個人的に応援しているYADIFAは議題に上がりませんでしたが、うん、まあ、まだそうかもね。

Q&A

Q. PowerDNSの比較ベンチマークで使った環境のOSは?
A. CentOS 7

Q. PowerDNSはDynamic Updateに対応しているか
A. 対応しています
 補足: 公式ドキュメント

Q. Unboundとdig +traceが相性悪いallow_snoop問題はdigを直せばいいのでは?
A. じゃあ藤原さんお願いします

Q. BINDのコードを見てるとあれをメインで使うのは良くない気が
A. じゃあ卒業しましょう
 私の感想: OpenSSL..

Q. 卒業ではなく兼用併用に進むべきでは?
A. おっしゃる通り
補足: DNS Diversityってやつですね

Q. BINDから卒業しちゃうとBINDで訊かれた時に答えられなくなるじゃないか
A. 「ウチはBINDじゃないので対象外ですキリッ」で
 私の感想: すごく日本っぽいけど弊社も言いそう

コメント. DoSられるとツライよね。特にキャプチャ..

コメント. DNS-WGとか行くと面白いよ!

Q. 権威サーバーで、TLDのような大きなゾーンを管理する場合とセカンダリーのように小さいゾーンをたくさん管理する場合とで向き不向きはあるか?
A. NSD -- ベンチマーク的にはそれほど差はなく、どちらにも使えそう。
    ただしゾーンのコンパイルにはそれなりの時間を要する
 PowerDNS -- その観点でベンチマークしたことは無いがSQLなのでそれほど差は無さそう

Q. なぜBINDはこんなに脆弱性が多いのか?
A. 発表の通り、ツールでチェックされているので多く露見している面もあるかも

Q. なぜBINDの脆弱性は致命的なものが多いのか?
A. サービスが落ちるだけであって「リモートから任意のコードを実行される」ではないのでマシかも

Q. NSDの動的ゾーン追加で内容が不正な場合の挙動は?
A. 読み込み失敗の場合はエラーになって終わり

Q. PowerAdmin GUIの使用感は楽になるor面倒?
A. プロは面倒に感じるところもあるかも
私の補足: プロ向けや自動化用のCLIと、作業の委譲用GUIと両方欲しいですよね。
     Webmin?あの子ゾーン内容をソートしますし..

Q. ベンチマークNSDのチューニングが甘いのでは?
A. そうかもしれません

コメント. DNSSECとかの機能にmoduleでの対応を意図している感じがする

コメント. Diversityな環境にすると運用負荷増えるような

Q. BINDから乗り換えるモチベーションは何?
A. 脆弱性が一番ですね。対応のためにrestartしてる時も一瞬落ちるわけですし

Q. ログ出力によるパフォーマンスの劣化は?
A. syslog経由ですがちょっとはありそう
私の感想: わかる。HDD性能が良くない環境で、クエリ毎秒が50分の1くらいに落ちた経験があります

コメント. MS DNSが挙がっていないが、開発版はそれなりに出来が良さそう

コメント. US vs EUとか英語圏 vs 非英語圏のような実装の対立を感じる
私の感想: NLnetLabとかもあって「なぜオランダはDNS開発してしまうのか問題」とかあった記憶が。
YADIFAはEURidによる開発なのでEURid本部のベルギーという位置付けのようです

コメント. 権威/再帰相乗り問題の対応は難しい。RDbitを見るんしても権威はフルオープンにせざるを得ない

コメント. アップデート提供ベンダーに過度に期待しない方が良い?脆弱性情報などはtwitterを追ってる方が得られる時代

私も2つ質問しました。

Q1. PowerDNSのGUIと言えばAtomiaDNSだった記憶があるが勢力図が変わったのか?
 元ネタ: DNSSEC2012スプリングフォーラム
A1. 今回は日本語が使えるのを重視してPowerAdminを選定
私の補足: 公式サイトの関連ツールにAtomia載ってないんですね..

Q2. 「BINDからの移行ツール」って意外とうまくいかなかったりしません?
 補足: 某商用製品での苦戦を念頭に置いています
A2. PowerDNSの移行ツールも100%対応、というわけではありません

午前の感想: どの実装でもクエリログの扱い触れていましたが、出力ログ+解析環境のセットが整っていないのがツライですよね。 dnstapがその解になるのか、キャプチャ+dscで頑張れ、が続くのか。
あと「BINDベースの商用製品」を使ってるのはBINDを卒業したのか、お金を払って沼に入ってるのか。

◎午後の部「トレンド」

逆引きDNSとその他の話題

Q. 3月のAPNIC障害は誤ったDSを載せちゃったと思われるが、IANA側での確認チェックは?
A. 詳しい人が懇親会に出るのでそちらで..

平成28年熊本地震と権威DNSサーバー

Q. キャッシュはどうなっていたか。ローカルキャッシュを見ていたとか
A. TTL 300だったので多分正しく切れていたはず

コメント. 非常時にNS切り替えはアリなのか?

Q. 他の自治体さんにも同じ問題が有りそう
A. セプターカウンシルで「こういう対策もしてね」と紹介している

コメント. 非常時には裏技でexpireを長~くしてしのいだこともあります by 大手プロバイダ

Q. ウェブサイトのIPアドレスはNSのレンジとは別だった?
A. そのようでした。ウェブサイトはDCのレンジにあるようです

私のコメント. zonemasterではDNSはASも分けて配置しようとアドバイスされます。それ割と難しいぞ

DNS水責め(Water Torture)攻撃対策と動向について 2016

Q. サーバー寄りの対策が多いがバランサーでは何かやっているか?
A. バランサーでは水責めに特化した対策はしていない
 高rateなもののみ制限している

Q. 「高ヒット率」とはフィルタを通過したものが多いということか?
A. オープンリゾルバのリストにハズレが多かったのが、精度の高いリストに更新されたのではないか

IP53Bはじめました

対応お疲れさまでした....

◎全体雑感

「BINDをやめられない理由アンケート」のコーナーはかなりぶった切り感があって、 困ってる人向けというよりは分かってる人が情報をアップデートしたりあるある感を楽しむ感じもしました。
そんな中「(今時のバージョンとスペックならば || よっぽどな大規模でカリカリにチューニングしてるのでなければ) パフォーマンスはBINDからの乗り換え理由にはならない」というのは一つ情報のアップデートになりました。 NSDやKnot(やYADIFA)のようにTLDでの使用をベースにした実装が多いのでベンチマーク情報が示されることが多いですからね。
その意味ではPowerDNSはちょっと立ち位置違って面白いのかなと思います。 ただPowerDNS、というか買収したOpenXchangeが数年前から妙にやる気というか商売意欲を出してる感が気になったり。
(ちなみにDebian系使ってるとpdnsというパッケージ名の方が略称としてもなじみがあるのですが、文中はPowerDNSの表記に統一しています)

BINDは脆弱性の数も課題ですが、これまでニュースになりすぎたためにユーザーやカスタマーも敏感になって 過度の騒ぎや対応になってしまっているのも問題だと感じています。
看板の付け替えだけでは本質的な解決にはならないですが、PowerDNSも4.0がリリースされましたし 今回ちょい役だったKnot DNSがResolver実装も出してきたりLTのXACKさんだったり、現実的な選択肢は増えていると思うので ユースケースや全体の構成例といった情報が増えてそれぞれに最適なDNS環境が作られていくといいなと感じました。

2016年3月10日木曜日

2016-03-10(日本時間)に公開されたbindアップデート関連まとめメモ

なんとなくDNS関係に話題がしぼられてきたこのブログですが

bind 9.9.8-P4および9.10.3-P4がリリースされました。
セキュリティ上の問題3件に対する修正が含まれています。
一番影響ありそうなCVE-2016-1286がワークアラウンド無しなのでアップデート不可避。


  • CVE-2016-1285
https://kb.isc.org/article/AA-01352/0
雑まとめ: リモートからcontrol channelに細工したパケットを送られるとサービスがexitする
対象: bind 9.Xほぼすべて (9.2.0 -> 9.8.8, 9.9.0->9.9.8-P3, 9.9.3-S1->9.9.8-S5, 9.10.0->9.10.3-P3)
回避策: rndc接続をlocalhostのみなどに制限する。(デフォルトはlocalhostのみ)
     例: named.conf内
controls {   inet 127.0.0.1 port 953  allow { 127.0.0.1; } keys { "rndc.key"; }; };

  • CVE-2016-1286
https://kb.isc.org/article/AA-01353/0
雑まとめ: DNAMEレコードの処理において、サービスがexitする場合がある
      ("specific properties"の内容未確認)
対象: bind 9.Xのほぼすべて (9.0.0 -> 9.8.8, 9.9.0 -> 9.9.8-P3, 9.9.3-S1 -> 9.9.8-S5,  9.10.0 -> 9.10.3-P3)
    リゾルバサーバーとして動いている場合は命中。ただし権威サーバーも、スレーブがマスターに送るSOA問い合わせとかのクエリで回答を細工されると被弾
回避策: アップデートしかない

  • CVE-2016-2088
https://kb.isc.org/article/AA-01351/0
雑まとめ: bind 9.10のDNS Cookie処理に問題がある
対象: bind 9.10系列 (9.10.0 -> 9.10.3-P3)
回避策: DNS Cookie(Source Identity Tokens)サポートを無効にする
     コンパイルオプション"--enable-sit"の部分(named.confではない)
     RHEL7.2やUbuntu 14.04は9.9系なのでセーフ。Ubuntu 16.04が9.10だが未詳


なお、OpenSSLではCritical./High/Medium/Lowの4段階でしたが、ISCはCritical & Catastorophic/Critical/High/Medium/Lowの5段階とのことです。
https://kb.isc.org/article/AA-00861/0/ISC-Software-Defect-and-Security-Vulnerability-Disclosure-Policy.html

(3/17追記)

2016年2月17日水曜日

CVE-2015-7547関連のbindパラメータメモ

CVE-2015-7547 はglibcの問題なのですが、getaddrinfo()の処理など名前解決処理に関する不具合で、緩和策にDNS関連のトピックも挙がっているのでひとまず整理しました。

https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html で挙げられている緩和策部分を抽出すると、
- Mitigating factors for UDP include:
  - A firewall that drops UDP DNS packets > 512 bytes.
  - A local resolver (that drops non-compliant responses).
  - Avoid dual A and AAAA queries (avoids buffer management error) e.g.
    Do not use AF_UNSPEC.
  - No use of `options edns0` in /etc/resolv.conf since EDNS0 allows
    responses larger than 512 bytes and can lead to valid DNS responses
    that overflow.
  - No use of `RES_USE_EDNS0` or `RES_USE_DNSSEC` since they can both
    lead to valid large EDNS0-based DNS responses that can overflow.
- Mitigating factors for TCP include:
  - Limit all replies to 1024 bytes.
反射攻撃やDNSフラグメンテーションが話題になった時のパラメータと顔ぶれが似てますね。
クライアント機器(スタブリゾルバ)で設定すべきものとリゾルバサーバーで設定できるものとありますが、
ひとまずbindのnamed.conf設定で該当するのは以下となります。
edns-udp-size
max-udp-size
どちらもデフォルト値は4096 bytesです。RFC6891を汲んでの値と思われます。
IPv6やDNSSECの要請でサイズが大きくなってきたところに512という小さい値の要求はキビシイ内容ですね....
素直にglibcアップデートを適用しましょう。
glibcなのでOSレベルでのリブートを行うことになるでしょうね..
 
(適宜更新します 


2016年1月26日火曜日

yadifa過去の資料リンク集

.euドメインを管理するEURidが開発しているDNSサーバーソフトウェアである
yadifaについて、これまでに開発陣が行った資料へのリンクをまとめていました。
git公開もされておらず、比較的情報の少ないyadifaですが、
「.euを管理する立場としてこういうのが欲しいんだ」というところも語られているので
そういった面から理解していくのもありかと思います。
ゾーンのダイナミック管理はknotとかもやってるみたいですね。

RIPE63
https://ripe63.ripe.net/presentations/154-RIPE63-DNSWG-BeyondBindAndNSD-PeterJanssenEURID.pdf

2012/02/14 Domain Pulse
http%3A%2F%2Fwww.domainpulse.de%2Fdownload%2Fpictures%2F42%2Fdn9dcn9w6v2b6ewakjjlkwa3bxnhbj%2Fdp_20120214_janssen.pdf


2012/04/18 RIPE64
https://ripe64.ripe.net/presentations/132-RIPE64-YADIFA.pdf
Dynamic Provisioning(DDNSではなくゾーン自体の追加削除をダイナミックに行う仕組み)の説明も


2013/03/21 WHD.global 2013
http://www.whd.global/downloads/2013/sStag3c1.pdf


2013/05/15 RIPE66
https://ripe66.ripe.net/presentations/207-YADIFA-RIEP66-DynamicProvisioning-pres.pdf
Dynamic Zone Managementについて


WHD.global 2014
http://www.whd.global/downloads/2014/hStag3d3.pdf
EURidの.eu管理全体(ドメイン発行~Webサイト公開環境提供)の俯瞰


2014/05 RIPE68
https://ripe68.ripe.net/presentations/284-AnandBuddhdev_RIPE68_DNS_Update.pdf
DNSのダイバーシティの話題。YADIFAはまだbuggyと評されている..

2014/10/13 ICANN51
https://la51.icann.org/en/schedule/mon-tech/presentation-yafida-13oct14-en
"2 developers"という衝撃情報

2016年1月20日水曜日

CVE-2015-8704まとめメモ

https://kb.isc.org/article/AA-01335/0

対象バージョン:
9.3.0->9.8.8,
9.9.0->9.9.8-P2, 9.9.3-S1->9.9.8-S3,
9.10.0->9.10.3-P2
権威サーバー、リゾルバサーバーどちらも該当

RFC3123で定められているAPL RRの処理に不具合があり、
特殊な内容を処理するとINSIST failureで異常終了する。

(追記: 冒頭のISCサイトで記載されているサンプルケース
 権威スレーブサーバーが権威マスターサーバーから特殊なレコードを受け取った場合
 権威マスターサーバーがDDNS updateで特殊なレコードを受け取った場合
 リゾルバサーバーが(debug logginしている場合に)特殊な回答を(悪意ある)権威サーバーから受け取った場合
 特殊な内容をキャッシュしている状態でrndc dumpdbした場合
 コード読めていませんがいずれもテキストファイルに書き出すと引っかかるみたいですね)

RFC3123: http://tools.ietf.org/html/rfc3123
EXPERIMENTAL
アドレスレンジ情報をDNSに載せるための実装らしい。初めてみましたが
foo.example.             IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
のように記述するそうです。
やりたいことは理解できる気がします。
 
ディストリビューター対応リンク
https://access.redhat.com/security/cve/CVE-2015-8704
サポート中のRHEL5~7すべて該当
(追記: 1/27にリリースされました) 

https://www.debian.org/security/2016/dsa-3449
Debianも該当
 
過去の記憶のせいでINSISTって見るとかなり嫌な感じがします。