タグ

bindに関するbeneluxのブックマーク (17)

  • BIND へのゾーンファイル設定方法 | XpressOne Knowledge Base 「サポート技術情報」

    記事では、CentOS/RedHat Enterprise Linux 環境において、インストールされたBIND DNSサーバーにお客様がお持ちのドメインを運用するために必要なゾーンファイル設定方法を解説します。 ゾーンファイルとは、そのドメインのホスト情報を表記するものでこの設定無しにドメイン運用は行なえないものです。 ※記事では 参考記事: BIND(DNSサーバー)インストールについて CentOS4.x BIND(DNSサーバー)インストールについて RHEL ES 4.x BIND(DNSサーバー)インストールについて CentOS5.x/RHEL5.x を参考に構築されたBIND コンテンツサーバー環境を対象としています。 上記参考記事と異なる方法で構築された環境には記事内容が適用できない場合があります、ご了承くださいませ。 1. 記事作成に利用した環境 参考記事をもと

  • BIND8, BIND9の設定 (Windows) | 法人向けOCN

    C:\winnt\system32\dns\etc\named.conf - namedプログラムの設定ファイル C:\winnt\system32\dns\etc\named.root - ルートキャッシュファイル(予めダウンロードしておいたファイルをetcフォルダに保存) C:\winnt\system32\dns\etc\example.com.zone - ドメイン「example.com」の正引きゾーンファイル C:\winnt\system32\dns\etc\32.69.168.192.in-addr.arpa.zone - ネットワーク「192.168.69.32/28」の逆引きゾーンファイル C:\winnt\system32\dns\etc\0.0.127.in-addr.arpa.zone - ループバック「127.0.0.1」の逆引きゾーンファイル named.co

  • 権威DNSサーバーにおける設定の基本を教えてください(BIND編)

    BIND 9.8系を例にとり、Linux(RHEL 6、CentOS 6)上における権威DNSサーバーのインストール、環境設定とゾーンの設定方法を解説する。 権威DNSサーバーにおける設定の基は、DNSサーバーそのものの設定とゾーンファイルの設定の2つにある。 そのポイントには、例えば再帰検索要求を無効にするかどうか、どこからの接続を許可するかなどがある。設定を誤ると、場合によってはオープンリゾルバーなど好ましくない状態になってしまうため、設定内容には注意が必要だ。 ゾーンファイルは、権威DNSサーバーが管理するゾーンの情報を記述するファイルである。ゾーンファイルに誤った内容が記述されていると、その内容がそのまま公開されてしまうことになるため、こちらについても十分な注意が必要だ。 ここでは、Linux(RHEL 6、CentOS 6)上における権威DNSサーバーの構成方法を、権威DNS

    権威DNSサーバーにおける設定の基本を教えてください(BIND編)
  • RHEL 互換の BIND バージョンアップ手順メモ | まこぴかっと

    どこぞで BIND アップデートが盛り上がっていたので、自分も便乗。 Rev.2016/11/25:querylog 周辺の追記と、手順一部見直し。 ■アップデータの確認 # yum check-update bind\* →これでバージョン確認。基的にRHEL 系は、ベースバージョン変わらないはず。 ■ダウングレードパッケージの確認 # rpm -qa bind\* →これらをインストールパッケージ、ちゃんと持っているよね? 切り戻しありきで構えておかないと危険。 ■Configのバックアップ # cp -piav /etc/named.conf /etc/named.conf.YYYYMMDD →過去に何度かRedHatが「Configを上書きする」というバグやらかしてるので。 ■保持しているゾーンの数確認 # rndc status →number of zones を確認する。ア

  • BINDの脆弱性対応についての動きまとめ - infragirl’s blog

    おはこんばんにちは。ナツヨです。 いつか、脆弱性対応についての記事を書こうと思っていたら、BINDさんがまた 脆弱性を発表してくれました。(CVE-2015-8704,CVE-2015-8705) 前回の発表から1ヶ月も立っていないのに、流石BINDさんだなぁと思いました。(遠い目) 今日は、BINDに焦点をあてて、脆弱性対応とはどういうことが必要なのかまとめていこうと思います。すでに日常的に脆弱性対応されている方というよりは、「なんかしらんけどDNSサーバの管理者になっていた。とりあえずBINDというソフトウェアで動いていることは知っている」という方向けだと思います。 1.BINDの脆弱性の発表をキャッチする BINDの脆弱性について、世の中で一番早く発信するのはBINDのサポートを行っているISC家(BIND | Internet Systems Consortium)だと思います。

    BINDの脆弱性対応についての動きまとめ - infragirl’s blog
    benelux
    benelux 2016/01/28
    ML登録するかな。
  • http://jprs.jp/tech/material/IW2003-DNS-DAY-dns-comparison-morishita.pdf

  • (緊急)BIND 9.10.2/9.9.7の脆弱性(DNSサービスの停止)について(2015年9月3日公開)

    --------------------------------------------------------------------- ■(緊急)BIND 9.10.2/9.9.7の脆弱性(DNSサービスの停止)について(2015年9月3日公開) - フルリゾルバー(キャッシュDNSサーバー)/権威DNSサーバーの双方が対象、 バージョンアップを強く推奨 - 株式会社日レジストリサービス(JPRS) 初版作成 2015/09/03(Thu) --------------------------------------------------------------------- ▼概要 BIND 9.10.2/9.9.7における実装上の不具合により、namedに対する外部から のサービス不能(DoS)攻撃が可能となる脆弱性が、開発元のISCから発表さ れました。脆弱性により、提供者

    benelux
    benelux 2015/09/03
    bind脆弱性夏祭り開催中…?
  • DNSキャッシュサーバ チューニングの勘所

    Software Design誌にて、来月より6ヶ月連続で、 「(VMware x Kubernetes) はじめよう、おうちクラウド」 という連載が2021年10 月18日より開始されるため、 宣伝も兼ねて、DevOps meetup に登壇しました。

    DNSキャッシュサーバ チューニングの勘所
  • Geekなぺーじ : 一般化するDNSブロッキング機能

    2ヶ月前の記事ですが、ISC BINDにブロッキング機能が標準搭載されるという発表がありました。 BIND(Berkeley Internet Name Domain)は、オープンソースのフリーソフトで、世界で最も利用されているDNSサーバです。 このBINDにブロッキング機能が搭載される予定であると発表されることには、非常に大きな意味があります。 ある意味、DNSブロッキングがインターネットの標準機能へと近づいていることを示唆しているのかも知れません。 その発表はBIND作者であるPaul Vixie氏によって行われましたが、最初の一文が「新しいドメイン名の大半は悪意のあるものだ」というものでした。 犯罪目的で取得されたドメイン名があまりに多いことを嘆きつつ、ISC BINDにDNSブロッキング機能を実装したことを報告しています。 「Taking Back the DNS | Inter

  • dns-memo.info - 

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

  • BIND 9を徹底活用するためのTips集

    BIND標準ツールの活用 サービスダウン時の自動回復 突然namedプロセスが落ちることがまれにあります。2Gbytesのゾーンファイルを複数持っているゾーンサーバや、recursive-clientsが限界に達しているキャッシュサーバでは、その確率が高くなります。そのため、プロセスが立ち上がっているか否かを常時監視する必要が生じます。実用qmailサーバ運用・管理術 第9回で、qmailのプロセスをdaemontoolsによって監視する方法を紹介しています。これを応用して、namedプロセスにもdaemontoolsを適用する方法が考えられますが、単純なプロセス監視だけでは名前解決を正常に行っているかどうかを見張ることができません。 そこで、BIND 9のソースディレクトリにあるPerlスクリプト「nanny.pl」を使用します。nanny.plはデーモンプロセスとしてシステムに常駐し、

    BIND 9を徹底活用するためのTips集
  • @IT:DNS Tips:SOAレコードには何が記述されている?

    ドメイン名のツリー構造は委任によってゾーンに分割され、分散管理されています。SOAレコードはこれらの分割されたゾーンそれぞれのオーソリティ情報が記されているレコードです。SOAはStart Of Authorityの略で、「権威の開始」という意味になります。 BINDではゾーンファイルの先頭、デフォルトTTLの指定の後に書くことになっています。また、SOAは委任に関するオーソリティ情報を記すものであり、各ゾーンの委任されたドメイン名に関連付けられます。 SOAレコードはゾーンファイルの中では、リスト1のように記述されます。 @ IN SOA  ns1.example.jp. postmaster.example.jp. ( 2003081901  ; Serial 3600        ; Refresh 900        ; Retry 604800     ; Expire 36

  • 技術解説:「DNS Reflector Attacks(DNSリフレクター攻撃)」について

    --------------------------------------------------------------------- ■技術解説:「DNS Reflector Attacks(DNSリフレクター攻撃)」について 株式会社日レジストリサービス(JPRS) 初版作成 2013/04/18(Thu) --------------------------------------------------------------------- ▼はじめに 2013年3月16日(協定世界時)[CISCO2013]から3月下旬にかけ、迷惑メール 対策の活動を進めている国際組織The Spamhaus Projectに対する攻撃に端を 発する、大規模かつ長期間にわたる分散サービス不能(DDoS)攻撃が発生し ました。 今回の攻撃ではこれまでで最大規模となる300Gbps以上のトラフィ

  • UnboundとNSDの紹介 BIND9との比較編

    1. UnboundとNSDの紹介 BIND9との比較編 日Unboundユーザ会 東 大亮 (平会員) オープンソースカンファレンス 2014 Tokyo/Fall 2014/10/19 1 2. 日Unboundユーザ会に ついて • 滝澤さん (@ttkzw) が運営されてる謎の会 • http://unbound.jp • UnboundやNSDやldnsのマニュアルの翻訳等 • 家 (http://unbound.net) からも公認されてる • 私はユーザ会のMLに参加してるだけ…… 2

    UnboundとNSDの紹介 BIND9との比較編
  • Mobageの技術を体験(MyDNS編)

    4. BINDとMyDNS ・OSSのDNSサーバとしてはBINDが有名 ・何が違う? - BINDはこのようなファイル形式でレコード情報格納 options { $TTL 86400 directory "/var/named"; @ IN SOA localhost. root.localhost. ( pid-file "/var/run/named/named.pid"; 2003121301 ; serial listen-on-v6{ 3600 ; refresh 1hr any; (1) 900 ; retry 15min } 604800 ; expire 1w }; 86400 ; min 24hr ) zone "localhost" { IN NS localhost. type master; IN A 127.0.0.1 file "local.zone"; IN

    Mobageの技術を体験(MyDNS編)
  • VPSで使用する独自ドメインを自前のDNSサーバで運用する | 作業ログ

    VPSを使用する場合、多くの場合は独自ドメインを取得して使用することになるかと思いますが、その独自ドメインのDNSサーバの運用方法は大きく以下の3つになると思います。 ドメインを取得した会社のDNSサーバを使用する 外部のDNSサーバを使用する VPSサーバでDNSサーバを運用する ドメインの登録会社は多くの場合DNSサーバのサービスを提供していると思います。そのサービスで問題なければ一番手堅い方法です。今回はムームードメインで取得したドメインを使用しますが、ムームードメインでは関連サービスを使う用途以外のDNSサーバの設定はできません。 世の中にはDNSのサービスのみを提供しているものを多数あると思います。例えばFreeDNSというフリーのDNSサービスなどはフリーにもかかわらず自由度の高い設定が可能なのではないでしょうか。 今回は独自ドメインを使用するVPSサーバ自身で自前のDNSサー

  • 「DNS浸透問題」は脆弱性だった!「幽霊ドメイン名脆弱性」:Geekなぺーじ

    「浸透いうな!」という掛け声が一部界隈で有名な「DNS浸透問題(もしくは、DNS浸透いうな問題)」ですが、今年2月にDNS浸透問題の原因の一つとなっている現象と同じものに起因する新たな脆弱性が発表されました。 その名は「幽霊ドメイン名脆弱性(ghost domain names)」です。 一見、DNS浸透問題とは全く別の問題のように思える「幽霊ドメイン名脆弱性」ですが、それが発生する原因と状況をよく見ると、「あ!これってDNS浸透問題で言ってた話と同じ原因だよね!?」とわかります。 実際、後述する通り、幽霊ドメイン名脆弱性の発想をDNS浸透問題と組み合わせることで、他人のDNS引っ越しを妨害するDoS攻撃も可能になります。 そう考えると、問題発生原因を調べずに「DNSの浸透をお待ち下さい」で済ませてしまうのは脆弱性の放置であるという考え方もできそうです(*1)。 ここでは、幽霊ドメイン名脆

  • 1