RFC1713 日本語訳

Network Working Group                                           A. Romao
Request for Comments: 1713                                          FCCN
FYI: 27                                                    November 1994
Category: Informational

コメントを求めるワーキンググループA.ロマンの要求をネットワークでつないでください: 1713FCCN FYI: 1994年11月27日のカテゴリ: 情報

                        Tools for DNS debugging

DNSデバッグのためのツール

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   Although widely used (and most of the times unnoticed), DNS (Domain
   Name System) is too much overlooked, in the sense that people,
   especially administrators, tend to ignore possible anomalies as long
   as applications that need name-to-address mapping continue to work.
   This document presents some tools available for domain administrators
   to detect and correct those anomalies.

広く使用される、(現代の大部分、目だたなさ、)、また、DNS(ドメインネームシステム)は非常に見落とされます、人々(特に管理者)が、名前からアドレス・マッピングを必要とするアプリケーションが、働き続けている限り、可能な例外を無視する傾向があるという意味で。 このドキュメントはドメイン管理者がそれらの例外を検出して、修正するように利用可能ないくつかのツールを提示します。

1. Introduction

1. 序論

   Today more than 3,800,000 computers are inter-connected in a global
   Internet [1], comprising several millions of end-users, able to reach
   any of those machines just by naming it.  This facility is possible
   thanks to the world widest distributed database, the Domain Name
   System, used to provide distributed applications various services,
   the most notable one being translating names into IP addresses and
   vice-versa.  This happens when you do an FTP or Telnet, when your
   gopher client follows a link to some remote server, when you click on
   a hypertext item and have to reach a server as defined by the URL,
   when you talk to someuser@some.host, when your mail has to be routed
   through a set to gateways before it reaches the final recipient, when
   you post an article to Usenet and want it propagated all over the
   world.  While these may be the most visible uses of DNS, a lot more
   applications rely on this system to operate, e.g., network security,
   monitoring and accounting tools, just to mention a few.

今日、380万台以上のコンピュータが世界的なインターネット[1]でインタコネクトされます、エンドユーザの数個の数百万を包括して、まさしくそれを命名するそれらのマシンのいずれにも達することができます。 この施設は世界の最も広い分散データベースへの感謝(ドメインネームシステム)が以前はよく様々なサービスを分配されたアプリケーションに提供していたのが可能です、最も注目に値するものがIPアドレスに名前を翻訳することであって逆もまた同様です。 あなたがFTPかTelnetをすると、これは起こります、あなたのリスクライアントが何らかのリモートサーバへのリンクの後をつけると、あなたがハイパーテキスト項目をクリックして、URLによって定義されるようにサーバに達しなければならないと、あなたが someuser@some.host と話すとき、最終的な受取人に届く前にあなたのメールがセットを通してゲートウェイに発送されなければならないとき、あなたがUsenetに記事を掲示して、それを世界中に伝播して欲しいときに。 これらはDNSの最も目に見える用途であるかもしれませんが、ずっと多くのアプリケーションが作動するためにこのシステムを当てにします、例えば、ネットワークセキュリティ、ただいくつかについて言及するためにツールをモニターして、説明して。

   DNS owes much of its success to its distributed administration.  Each
   component (called a zone, the same as a domain in most cases), is
   seen as an independent entity, being responsible for what happens
   inside its domain of authority, how and what information changes and
   for letting the tree grow downwards, creating new components.

DNSは分散型管理から成功の多くを借りています。 独立実体と考えられて、権威のドメインの中で起こることと、どのように、情報が変えるものと木が下向きに生えるかに責任があるので、新しいコンポーネントを作成する各コンポーネント(多くの場合、ゾーン、ドメインと同じくらいと呼びます)。

Romao                                                           [Page 1]

RFC 1713                Tools for DNS debugging            November 1994

1994年11月をデバッグするDNSのためのロマン[1ページ]RFC1713Tools

   On the other hand, many inconsistencies arise from this distributed
   nature: many administrators make mistakes in the way they configure
   their domains and when they delegate authority to sub-domains; many
   of them don't even know how to do these things properly, letting
   problems last and propagate.  Also, many problems occur due to bad
   implementations of both DNS clients and servers, especially very old
   ones, either by not following the standards or by being error prone,
   creating or allowing many of the above problems to happen.

他方では、多くの矛盾がこの分配された自然から起こります: 多くの管理者が自己のドメインといつサブドメインに権限を委ねるかを構成する方法で誤りをします。 彼らの多くがどのように最後に問題をさせて、適切にこれらのことをして、伝播するかを知ってさえいません。 また、多くの問題がDNSクライアントとサーバ、特に非常に古いものの両方の悪い実装のため規格に続かないか、誤りであることで傾向があった状態で起こります、起こるように上の問題の多くを生じるか、または許容して。

   All these anomalies make DNS less efficient than it could be, causing
   trouble to network operations, thus affecting the overall Internet.
   This document tries to show how important it is to have DNS properly
   managed, including what is already in place to help administrators
   taking better care of their domains.

これらのすべての例外でDNSはそれであることができたほど効率的でなくなります、ネットワーク操作に問題を起こして、その結果、総合的なインターネットに影響します。 このドキュメントは、DNSを適切に管理させるのがどれくらい重要であるかを示そうとします、管理者が彼らのドメインの世話をするのを助けるために何が既に適所にあるかを含んでいて。

2. DNS debugging

2. DNSデバッグ

   To help finding problems in DNS configurations and/or implementations
   there is a set of tools developed specifically for this purpose.
   There is probably a lot of people in charge of domain administration
   having no idea of these tools (and, worse, not aware of the anomalies
   that may exist in their configurations).  What follows is a
   description of some of these programs, their scope, motivations and
   availability, and is hoped to serve as an introduction to the subject
   of DNS debugging, as well as a guide to those who are looking for
   something to help them finding out how healthy their domains and
   servers are.

そこでDNS構成、そして/または、実装における問題を見つけるのを助けるのは、明確にこのために開発された1セットのツールです。 たぶん、多くの人々がこれらのツールと(よりひどく意識しないそれらの構成で存在するかもしれない異常を)の考えを全く持っていないドメイン管理を担当しています。 続くことは、これらのプログラム、それらの範囲、動機、およびいくつかの有用性の記述であり、序論としてDNSデバッグの対象に機能するように望まれています、何か彼らが、彼らのドメインとサーバがどれくらい健康であるかを見つけるのを助けるものを探している人へのガイドと同様に。

   Some prior knowledge from the reader is assumed, both on DNS basics
   and some other tools (e.g., dig and nslookup), which are not analyzed
   in detail here; hopefully they are well-known enough from daily
   usage.

読者からの何らかの先の知識が想定されます、DNS基礎とある他のツール(例えば、皮肉とnslookup)で(ツールはここで詳細に分析されません)。 うまくいけば、それらは毎日の用法から十分周知のことです。

2.1. Host

2.1. ホスト

   Host is a program used to retrieve DNS information from name servers.
   This information may be used simply to get simple things like
   address-to-name mapping, or some more advanced purposes, e.g.,
   performing sanity checks on the data.  It was created at Rutgers
   University, but then Eric Wassenaar from Nikhef did a major rewrite
   and still seems to be actively working on improving it.  The program
   is available from ftp://ftp.nikhef.nl/pub/network/host_YYMMDD.tar.Z
   (YYMMDD is the date of the latest release).

ホストはネームサーバからのDNS情報を検索するのに使用されるプログラムです。 この情報は、単に命名するアドレスマッピング、またはそれ以上の高度な目的(例えば、データにおける実行健全度チェック)のような簡単なものを手に入れるのに使用されているかもしれません。 それがラトガース大学で作成されましたが、NikhefからのエリックWassenaarは主要な書き直しをして、活発にそれを改良するのに働いているようにまだ思えています。 プログラムは ftp://ftp.nikhef.nl/pub/network/host_YYMMDD.tar.Z から利用可能です(YYMMDDは最新のリリースの日付です)。

   By default, host just maps host names to Internet addresses, querying
   the default servers or some specific one.  It is possible, though, to
   get any kind of data (resource records) by specifying different query
   types and classes and asking for verbose or debugging output, from

デフォルトで、標準サーバーかいくつかの特定の1つについて質問して、ホストはただホスト名をインターネット・アドレスに写像します。 もっとも、異なった質問タイプとクラスを指定して、冗長であるかデバッグ出力を求めることによってどんな種類のデータ(リソース記録)も得るのは可能です。

Romao                                                           [Page 2]

RFC 1713                Tools for DNS debugging            November 1994

1994年11月をデバッグするDNSのためのロマン[2ページ]RFC1713Tools

   any name server.  You can also control several parameters like
   recursion, retry times, timeouts, use of virtual circuits vs.
   datagrams, etc., when talking to name servers.  This way you can
   simulate a resolver behavior, in order to find any problems
   associated with resolver operations (which is to say, any application
   using the resolver library).  As a query program it may be as
   powerful as others like nslookup or dig.

また、ネームサーバと話すとき、いくらか、ネームサーバあなたは再帰のようないくつかのパラメタ、再試行時間、タイムアウト、仮想の回路の対データグラム使用などを制御できます。 このように、あなたはレゾルバの振舞いをシミュレートできます、どんな問題もレゾルバ操作に関連しているのがわかるために(どんなアプリケーションもレゾルバライブラリを使用して、言うことになっています)。 質問プログラムとして、それは他のものがnslookupが好きである、または掘るのと同じくらい強力であるかもしれません。

   As a debugger, host analyzes some set of the DNS space (e.g., an
   entire zone) and produces reports with the results of its operation.
   To do this, host first performs a zone transfer, which may be
   recursive, getting information from a zone and all its sub-zones.
   This data is then analyzed as requested by the arguments given on the
   command line.  Note that zone transfers are done by contacting
   authoritative name servers for that zone, so it must be possible to
   make this kind of request from such servers: some of them refuse zone
   transfers (except from secondaries) to avoid congestion.

デバッガとして、ホストは、DNSスペース(例えば、全体のゾーン)の何らかのセットを分析して、操作の結果でレポートを製作します。 これをするために、ホストは最初にゾーン転送を実行します、ゾーンとそのすべてのサブゾーンから情報を得て。(ゾーン転送は再帰的であるかもしれません)。 そして、このデータは要求された通りコマンドラインで与えられた議論で分析されます。 そのようなサーバからこの種類の要求をするのが可能であるに違いないようにそのゾーンへ正式のネームサーバに連絡することによってゾーン転送をすることに注意してください: 彼らの何人かが、混雑を避けるために、ゾーン転送(代理人を除いた)を拒否します。

   With host you may look for anomalies like those concerning authority
   (e.g., lame delegations, described below) or some more exotic cases
   like extrazone hosts (a host of the form host.some.dom.ain, where
   some.dom.ain is not a delegated zone of dom.ain).  These errors are
   produced upon explicit request on the command line, but you may get a
   variety of other error messages as a result of host's operations,
   something like secondary effects.  These may be mere warnings (which
   may be suppressed) or serious errors - in fact, warning messages are
   not that simple, most of them are due to misconfigured zones, so it
   might not be a good idea to just ignore them.

ホストと共に、権威(例えば以下で説明された不十分な委譲)かそれ以上のエキゾチックなケースに関するものが「超-ゾーン」ホスト(some.dom.ainがdom.ainの代表として派遣されたゾーンでないところのフォームhost.some.dom.ainのホスト)が好きであるようにあなたは例外を探すことができます。 これらの誤りは明白な要求のときにコマンドラインで起こされますが、あなたはホストの操作の結果、他のさまざまなエラーメッセージを得ることができます、副次的効果のように。 これらは、単なる警告(抑圧されるかもしれない)か重大な誤りであるかもしれません--事実上、警告メッセージはただそれらを無視するのが、簡単です、それらの大部分がmisconfiguredゾーンのためである名案でないかもしれないということではありません。

   Error messages have to do with serious anomalies, either with the
   packets exchanged with the queried servers (size errors, invalid
   ancounts, nscounts and the like), or others related to the DNS
   information itself (also called "status messages" in the program's
   documentation): inconsistencies between SOA records as shown by
   different servers for a domain, unexpected address-to-name mappings,
   name servers not responding, not reachable, not running or not
   existing at all, and so on.

エラーメッセージは重大な例外と関係があります、どちらか質問されたサーバ(サイズ誤り、無効のancounts、nscounts、および同様のもの)で交換するパケットか他のものがDNS情報(また、プログラムのドキュメンテーションに「ステータスメッセージ」と呼ばれる)自体に関連する状態で: 稼働しているか、または全く、などに存在しているのではなく、予期していなかった命名するアドレスマッピング、ネームサーバが応じないで、ドメインにおいて、届いていない異なったサーバによって示されるSOA記録の間の矛盾。

   Host performs all its querying on-line, i.e., it only works with data
   received from name servers, which means you have to query a name
   server more than once if you want to get different kinds of reports
   on some particular piece of data.  You can always arrange arguments
   in such a way that you get all information you want by running it
   once, but if you forget something or for any reason have to run it
   again, this means extra zone transfers, extra load on name servers,
   extra DNS traffic.

ホストはオンラインですべての質問を実行します、すなわち、それが一度よりあなたがいくつかの特定のデータで異種のレポートを手に入れたいならネームサーバから受け取られたデータで働いているだけです。(データは、あなたがネームサーバについてさらに質問しなければならないことを意味します)。 あなたはいつもあなたが一度それを実行することによって欲しいすべての情報を得るような方法で議論をアレンジできますが、何かを忘れるか、またはそれが何か理由で再び走行にありましたらこれは付加的なゾーン転送を意味します、ネームサーバに関する上積みされた荷物、付加的なDNSトラフィック。

Romao                                                           [Page 3]

RFC 1713                Tools for DNS debugging            November 1994

1994年11月をデバッグするDNSのためのロマン[3ページ]RFC1713Tools

   Host is an excellent tool, if used carefully.  Like most other
   querying programs it may generate lots of traffic, just by issuing a
   simple command.  Apart from that, its resolver simulation and debug
   capabilities make it useful to find many common and some not so
   common DNS configuration errors, as well as generate useful reports
   and statistics about the DNS tree.  As an example, RIPE (Reseaux IP
   Europeens) NCC uses it to generate a monthly european hostcount,
   giving an overview of the Internet usage evolution in Europe.  Along
   with these counts, error reports are generated, one per country, and
   the whole information is made available in the RIPE archive.

ホストは、慎重に素晴らしいツールであって、使用されています。 他のほとんどの質問プログラムのように、それは、簡単なコマンドを発行するだけで多くのトラフィックを生成するかもしれません。 それは別として、そのレゾルバシミュレーションとデバッグ能力は、多くがコモンといくつかのあまりに一般的でないDNS構成誤りであることがわかるのを役に立つようにして、DNS木に関する役に立つレポートと統計を作ります。 例として、RIPE(Reseaux IP Europeens)NCCは毎月のeuropean hostcountを生成するのにそれを使用します、ヨーロッパでのインターネット用法発展の概要を与えて。 これらのカウントと共に、エラー・レポートは発生しています、1国あたり1つ、全体の情報をRIPEアーカイブで利用可能にします。

2.2. Dnswalk

2.2. Dnswalk

   Dnswalk is a DNS debugger written in Perl by David Barr, from
   Pennsylvania State University.  You'll find the latest version at
   ftp://ftp.pop.psu.edu/pub/src/dnswalk.  With the software comes a
   small document where the author points some useful advice so it may
   be worth reading it.

Dnswalkはデヴィッド・バールによってペンシルバニア州立大学からPerlで書かれたDNSデバッガです。 あなたは ftp://ftp.pop.psu.edu/pub/src/dnswalk で最新版を見つけるでしょう。 ソフトウェアが作者が何らかの役に立つアドバイスを指す小さいドキュメントにはついて来ているので、それを読む価値があるかもしれません。

   The program checks domain configurations stored locally, with data
   arranged hierarchically in directories, resembling the DNS tree
   organization of domains.  To set up this information dnswalk may
   first perform zone transfers from authoritative name servers. You can
   have a recursive transfer of a domain and its sub-domains, though you
   should be careful when doing this, as it may generate a great amount
   of traffic.  If the data is already present, dnswalk may skip these
   transfers, provided that it is up to date.

プログラムはドメインのDNS木の組織に類似していて、データがディレクトリに階層的に配置されている状態で局所的に保存されたドメイン構成をチェックします。 この情報dnswalkをセットアップするのは最初に、正式のネームサーバからのゾーン転送を実行するかもしれません。 あなたはドメインとそのサブドメインの再帰的な転送を持つことができます、これをするとき、あなたは慎重であるはずですが、多くのトラフィックを生成するとき。 データが既に存在しているなら、それが最新であれば、dnswalkはこれらの転送をサボるかもしれません。

   Dnswalk looks for inconsistencies in resource records, such as MX and
   aliases pointing to aliases or to unknown hosts, incoherent PTR, A
   and CNAME records, invalid characters in names, missing trailing
   dots, unnecessary glue information, and so on.  It also does some
   checking on authority information, namely lame delegations and
   domains with only one name server.  It is easy to use, you only have
   to specify the domain to analyze and some optional parameters and the
   program does the rest.  Only one domain (and its sub-domains, if
   that's the case) can be checked at a time, though.

Dnswalkは別名を示すMXや別名などのリソース記録か未知のホスト、支離滅裂のPTR、A、CNAME記録、名前の無効のキャラクタ、なくなった引きずっているドット、不要な接着剤情報などとして矛盾を探します。 また、それは1つのネームサーバだけですなわち、権威情報、ラメにおける何らかの照合に委譲とドメインをします。使用するのは簡単です、そして、あなたは分析するドメインといくつかの任意のパラメタを指定するだけでよいです、そして、プログラムは残りをします。 1つのドメインだけ、(そして、サブドメイン、それである、もっとも、ケース) 缶は一度に、チェックされましたか?

   While in the process of checking data, dnswalk uses dig and resolver
   routines (gethostbyXXXX from the Perl library) a lot, to get such
   data as authority information from the servers of the analyzed
   domains, names from IP addresses so as to verify the existence of PTR
   records, aliases and so on.  So, besides the zone transfers you may
   count on some more extra traffic (maybe not negligible if you are
   debugging a relatively large amount of data and care about query
   retries and timeouts), just by running the program.

データを調べることの途中に使用している間、dnswalkは、PTR記録、別名などの存在について確かめるためにIPアドレスからの分析ドメインのサーバ、名前からの権威情報のようなデータを得るのに、皮肉とレゾルバルーチン(PerlライブラリからのgethostbyXXXX)を大いに使用します。 したがって、ゾーン転送以外にあなたがそれ以上の付加的なトラフィックを頼りにすることができる、(多分取るにたらなくない、あなたは質問再試行に関して比較的大データ量と注意をデバッグしているかどうか、そして、タイムアウト) プログラムを動かすことによって、正当です。

Romao                                                           [Page 4]

RFC 1713                Tools for DNS debugging            November 1994

1994年11月をデバッグするDNSのためのロマン[4ページ]RFC1713Tools

2.3. Lamers

2.3. Lamers

   A lame delegation is a serious error in DNS configurations, yet a
   (too) common one.  It happens when a name server is listed in the NS
   records for some domain and in fact it is not a server for that
   domain.  Queries are thus sent to the wrong servers, who don't know
   nothing (at least not as expected) about the queried domain.
   Furthermore, sometimes these hosts (if they exist!) don't even run
   name servers.  As a result, queries are timed out and resent, only to
   fail, thus creating (more) unnecessary traffic.

しかし、不十分な委譲はDNS構成における重大な誤り、(また)一般的なものです。 ネームサーバが何らかのドメインのためのNS記録に記載されているとき、それは起こります、そして、事実上、そのドメインへのサーバではありません。 このようにして間違ったサーバに質問を送ります。(サーバは質問されたドメインに関して何(少なくとも予想されないように)も知りません)。 その上、時々、これらのホスト(彼らが存在するなら!)はネームサーバを実行さえしません。 その結果、その結果、(より多く)の不要なトラフィックを作成して、質問を外で調節して、再送しますが、失敗します。

   It's easy to create a lame delegation: the most common case happens
   when an administrator changes the NS list for his domain, dropping
   one or more servers from that list, without informing his parent
   domain administration, who delegated him authority over the domain.
   From now on the parent name server announces one or more servers for
   the domain, which will receive queries for something they don't know
   about.  (On the other hand, servers may be added to the list without
   the parent's servers knowing, thus hiding valuable information from
   them - this is not a lame delegation, but shouldn't happen either.)
   Other examples are the inclusion of a name in an NS list without
   telling the administrator of that host, or when a server suddenly
   stops providing name service for a domain.

不十分な委譲を作成するのは簡単です: 管理者が彼のドメインのためのNSリストを変えると、最も一般的なケースは起こります、そのリストから1つ以上のサーバを下げて、彼の親ドメイン管理に知らせないで。(管理は彼のためにドメインの上へ権威を代表として派遣しました)。 これから先、親ネームサーバは1つ以上のサーバをドメインに発表します。(それは、彼らが知らない何かのための質問を受けるでしょう)。 (親のサーバが知らないで、他方では、サーバはリストに追加されるかもしれません、その結果、それらから貴重な情報を隠します--これは、不十分な委譲ではありませんが、起こるべきではありません。) 他の例はそのホストの管理者かそれともサーバが、いつドメインのための名前サービスを提供するのを突然止めるかを言うことのないNSリストにおける名前の包含です。

   To detect and warn DNS administrators all over the world about this
   kind of problem, Bryan Beecher from University of Michigan wrote
   lamers, a program to analyze named (the well-known BIND name server)
   logging information [2].  To produce useful logs, named was applied a
   patch to detect and log lame delegations (this patch was originally
   written by Don Lewis from Silicon Systems and is now part of the
   latest release of BIND thanks to Bryan Beecher, so it is expected to
   be widely available in the near future).  Lamers is a small shell
   script that simply scans these logs and reports the lame delegations
   found.  This reporting is done by sending mail to the hostmasters of
   the affected domains, as stated in the SOA record for each of them.
   If this is not possible, the message is sent to the affected name
   servers' postmasters instead.  Manual processing is needed in case of
   bounces, caused by careless setup of those records or invalid
   postmaster addresses.  A report of the errors found by the U-M
   servers is also posted twice a month on the USENET newsgroup
   comp.protocols.tcp-ip.domains.

ミシガン大学からのビーチャーがlamersに書いたとこの種類の問題に関する世界中のDNS管理者、ブライアンに検出して、警告するために、分析するプログラムは(よく知られるBINDネームサーバ)を伐採情報[2]と命名しました。 役に立つログであって、命名されていた状態で生産するのによる適用されて、検出するパッチとログが委譲を不完全にするという(このパッチが元々、ドン・ルイスによってSilicon Systemsから書かれて、現在ブライアンBeecherのおかげでBINDの最新のリリースの一部であるので、近い将来広く利用可能であると予想されます)ことでした。 Lamersは単に不十分な委譲が見つけたこれらのログとレポートをスキャンする小さいシェルスクリプトです。 影響を受けるドメインのhostmastersにメールを送ることによって、この報告をします、それぞれのそれらのためのSOA記録に述べられているように。 これが可能でないなら、代わりに影響を受けるネームサーバの郵便局長にメッセージを送ります。 手動の処理がそれらの記録か無効の郵便局長アドレスの不注意なセットアップで引き起こされた弾みの場合に必要です。 また、U-Mサーバによって見つけられた誤りのレポートはユーズネットcomp.protocols.tcp-ip.domainsの上の1カ月に二度掲示されます。

   If you ever receive such a report, you should study it carefully in
   order to find and correct problems in your domain, or see if your
   servers are being affected by the spreading of erroneous information.
   Better yet, lamers could be run on your servers to detect more lame
   delegations (U-M can't see them all!).  Also, if you receive mail
   reporting a lame delegation affecting your domain or some of your

そのようなレポートを受け取るなら、あなたは、あなたのドメインで問題を見つけて、修正するか、またはあなたのサーバが影響を受けているかどうかを間違った情報の普及で見るために慎重にそれを研究するべきです。 さらに良く、lamersは、より不十分な委譲を検出するためにはあなたのサーバにおける走行であるかもしれません(U-Mはそれらを皆、見ることができません!)。 また、受信するならaがあなたのドメインに影響する委譲かいくつかを不完全にする報告を郵送してください、あなた

Romao                                                           [Page 5]

RFC 1713                Tools for DNS debugging            November 1994

1994年11月をデバッグするDNSのためのロマン[5ページ]RFC1713Tools

   hosts, please don't just ignore it or flame the senders.  They're
   really trying to help!

ホストは、ただそれを無視しないでください、または送付者を燃やさないでください。 彼らは本当に助けようとしています!

   You can get lamers from ftp://terminator.cc.umich.edu/dns/lame-
   delegations.

あなたは ftp://terminator.cc.umich.edu/dns/lame- 委譲からlamersを手に入れることができます。

2.4. DOC

2.4. DOC

   Authority information is one of the most significant parts of the DNS
   data, as the whole mechanism depends on it to correctly traverse the
   domain tree.  Incorrect authority information leads to problems such
   as lame delegations or even, in extreme cases, the inaccessibility of
   a domain.  Take the case where the information given about all its
   name servers is incorrect: being unable to contact the real servers
   you may end up being unable to reach anything inside that domain.
   This may be exaggerated, but if you're on the DNS business long
   enough you've probably have seen some enlightened examples of this
   scenario.

権威情報はDNSデータの最も重要な部分の1つです、全体のメカニズムが正しくドメイン木を横断するためにそれによるとき。 不正確な権威情報は不十分な委譲か極端な場合における、ドメインの近づきにくさなどさえの問題を引き起こします。 すべてのネームサーバに関して与えられた情報が不正確であるケースを取ってください: あなたが連絡できる実際のサーバに連絡できないで、結局、そのドメインの中で何にも達することができないでください。 これは誇張されるかもしれませんが、十分長いDNSビジネスにいるなら、あなたは、或るものがこのシナリオに関する例を啓発したのをたぶん見ました。

   To look for this kind of problems Paul Mockapetris and Steve Hotz,
   from the Information Sciences Institute, wrote a C-shell script
   called DOC (Domain Obscenity Control), an automated domain testing
   tool that uses dig to query the appropriate name servers about
   authority for a domain and analyzes the responses.

情報Sciences Instituteから、この種類の問題を探すために、ポールMockapetrisとスティーブHotzはDOC(ドメインObscenity Control)と呼ばれるC-シェルスクリプトを書きました、権威に関して適切なネームサーバについてドメインに質問するのに皮肉を使用して、応答を分析する自動化されたドメインテストツール。

   DOC limits its analysis to authority data since the authors
   anticipated that people would complain about such things as invasion
   of privacy.  Also, at the time it was written most domains were so
   messy that they thought there wouldn't be much point in checking
   anything deeper until the basic problems weren't fixed.

作者が、人々がプライバシー侵害としてそのようなものの周りで不平を言うと予期したので、DOCは分析を権威データに制限します。 また、それが書かれたときほとんどのドメインが非常に乱雑であったので、それらは、基本的問題が修正されないまで、より深いものは何でもチェックする意味があまりないと思いました。

   Only one domain is analyzed each time: the program checks if all the
   servers for the parent domain agree about the delegation information
   for the domain.  DOC then picks a list of name servers for the domain
   (obtained from one of the parent's servers) and starts checking on
   their information, querying each of them: looks for the SOA record,
   checks if the response is authoritative, compares the various records
   retrieved, gets each one's list of NS, compares the lists (both among
   these servers and the parent's), and for those servers inside the
   domain the program looks for PTR records for them.

1つのドメインだけがその都度、分析されます: プログラムは、ドメインがないかどうか親ドメインへのすべてのサーバが委譲情報に関して同意するかどうかチェックします。 DOCは次に、ドメイン(親のサーバの1つから、得る)にネームサーバのリストを選んで、それらの情報について検査し始めます、それぞれのそれらについて質問して: SOA記録のための面相、チェックは応答であるなら正式であり、検索された様々な記録を比較して、それぞれのNSのリストを得て、リストを比較します、そして、(これらのサーバと親のものの中で)ドメインの中のそれらのサーバのために、プログラムはそれらのためのPTR記録を探します。

   Due to several factors, DOC seems to have frozen since its first
   public release, back in 1990.  Within the distribution there is an
   RFC draft about automated domain testing, which was never published.
   Nevertheless, it may provide useful reading.  The software can be
   fetched from ftp://ftp.uu.net/networking/ip/dns/doc.2.0.tar.Z.

いくつかの要素のため、DOCは、最初の公共のリリース以来1990年に凍っているように思えます。 中では、そこでの分配が自動化されたドメインテストに関するRFC草稿です。(それは、決して発行されませんでした)。 それにもかかわらず、それは役に立つ読書を提供するかもしれません。 ftp://ftp.uu.net/networking/ip/dns/doc.2.0.tar.Z からソフトウェアをとって来ることができます。

Romao                                                           [Page 6]

RFC 1713                Tools for DNS debugging            November 1994

1994年11月をデバッグするDNSのためのロマン[6ページ]RFC1713Tools

2.5. DDT

2.5. DDT

   DDT (Domain Debug Tools) is a package of programs to scan DNS
   information for error detection, developed originally by Jorge Frazao
   from PUUG - Portuguese UNIX Users Group and later rewritten by the
   author, at the time at the Faculty of Sciences of University of
   Lisbon.  Each program is specialized in a given set of anomalies: you
   have a checker for authority information, another for glue data, mail
   exchangers, reverse-mappings and miscellaneous errors found in all
   kinds of resource records.  As a whole, they do a rather extensive
   checking on DNS configurations.

DDT(ドメインDebug Tools)は元々ホルヘFrazaoによってPUUGから開発された誤り検出のためのDNS情報をスキャンするプログラムのパッケージです--時にリスボン大学のSciencesのFacultyで作者によって書き直されたポルトガルのUNIX Users Group以降。 各プログラムは与えられたセットの例外で専門にされます: あなたはすべての種類のリソース記録で見つけられた権威情報のための市松模様、接着剤データのための別のもの、メール交換器、逆マッピング、および種々雑多な誤りを飼っています。 全体で、彼らはDNS構成でかなり大規模な照合をします。

   These tools work on cached DNS data, i.e., data stored locally after
   performing zone transfers (presently done by a slightly modified
   version of BIND's named-xfer, called ddt-xfer, which allows recursive
   transfers) from the appropriate servers, rather than querying name
   servers on-line each time they run.  This option was taken for
   several reasons [3]: (1) efficiency, since it reads data from disk,
   avoiding network transit delays, (2) reduced network traffic, data
   has to be fetched only once and then run the programs over it as many
   times as you wish and (3) accessibility - in countries with limited
   Internet access, as was the case in Portugal by the time DDT was in
   its first stages, this may be the only practical way to use the
   tools.

これらのツールはキャッシュされたDNSデータ(すなわち、稼働しているたびにオンラインでネームサーバについて質問するより適切なサーバからゾーン転送をむしろ実行した(再帰的な転送を許容するddt-xferと呼ばれるBINDの命名されたxferのわずかに変更されたバージョンは現在、します)後に局所的に保存されたデータ)に取り組みます。 いくつかの理由[3]にこのオプションを取りました: (1) 効率、国で限られたインターネット・アクセスでディスク、ネットワークトランジット遅れ、あなたが願っているようにデータが一度だけとって来られて、次に、何回もそれの上のプログラムを動かすために持っている(2)の減少しているネットワークトラフィックを避けて、および(3)のアクセシビリティからデータを読むので、DDTが最初の段階にある時までにポルトガルでそうであったように、これはツールを使用する唯一の実用的な方法であるかもしれません。

   Point (2) above deserves some special considerations: first, it is
   not entirely true that there aren't additional queries while
   processing the information, one of the tools, the authority checker,
   queries (via dig) each domain's purported name servers in order to
   test the consistency of the authority information they provide about
   the domain.  Second, it may be argued that when the actual tests are
   done the information used may be out of date.  While this is true,
   you should note that this is the DNS nature, if you obtain some piece
   of information you can't be sure that one second later it is still
   valid.  Furthermore, if your source was not the primary for the
   domain then you can't even be sure of the validity in the exact
   moment you got it in the first place.  But experience shows that if
   you see an error, it is likely to be there in the next version of the
   domain information (and if it isn't, nothing was lost by having
   detected it in the past).  On the other side, of course there's
   little point in checking one month old data...

上のポイント(2)はいくつかの特別な問題に値します: まず最初に追加質問が情報を処理している間ないのが、完全に本当でない、ツールの1つ(権威市松模様)はそれらがドメインに関して提供する権威情報の一貫性をテストするために各ドメインの主張されたネームサーバについて質問します(皮肉で)。 2番目に、実際のテストが完了しているとき、使用される情報が時代遅れであるかもしれないと主張されるかもしれません。 これが本当である間、あなたは、これがDNS自然であることに注意するべきです、あなたがあなたが1秒後にそれがまだ有効であることを確信しているはずがないという情報の何らかの断片を得るなら。 その上、あなたのソースがドメインへの予備選挙でなかったなら、あなたは第一に得た正確な瞬間に正当性を確信してさえいるはずがありません。 しかし、経験は、あなたが誤りを見るなら、そこ、ドメイン情報の次のバージョンにいそうであるのを示します(それがそうでないなら、何も過去にそれを検出したことによって、失われませんでした)。 反対側では、1つの一カ月前のデータをチェックするのがもちろん無意味です…

   The list of errors looked for includes lame delegations, version
   number mismatches between servers (this may be a transient problem),
   non-existing servers, domains with only one server, unnecessary glue
   information, MX records pointing to hosts not in the analyzed domain
   (may not be an error, it's just to point possibly strange or
   expensive mail-routing policies), MX records pointing to aliases, A

探された誤りのリストは不十分な委譲を含んでいます、サーバの間のバージョン数のミスマッチ(これは過渡現象の問題であるかもしれない)、非既存のサーバ、1つのサーバだけがあるドメイン、不要な接着剤情報、MX記録がいずれの分析ドメイン(誤り、まさしくことによると奇妙であるか高価なメールルーティング方針を示すことになっているということでないかもしれない)にもホストを示さないで、MX記録が別名を示して、A

Romao                                                           [Page 7]

RFC 1713                Tools for DNS debugging            November 1994

1994年11月をデバッグするDNSのためのロマン[7ページ]RFC1713Tools

   records without the respective PTR and vice-versa, missing trailing
   dots, hostnames with no data (A or CNAME records), aliases pointing
   to aliases, and some more.  Given the specialized nature of each
   tool, it is possible to look for a well defined set of errors,
   instead of having the data analyzed in all possible ways.

それぞれのPTRのない記録と逆もまた同様です、なくなった引きずっているドット、データ(AかCNAME記録)のないホスト名、別名、およびそれ以上を示す別名。 それぞれのツールの専門化している本質を考えて、よく定義されたセットの誤りを探すのは可能です、データをすべての可能な方法で分析させることの代わりに。

   Except for ddt-xfer, all the programs are written in Perl.  A new
   release may come into existence in a near future, after a thorough
   review of the methods used, the set of errors checked for and some
   bug fixing (in particular, a Perl version of ddt-xfer is expected).
   In the mean time, the latest version is available from
   ftp://ns.dns.pt/pub/dns/ddt-2.0.1.tar.gz.

ddt-xferを除いて、すべてのプログラムがPerlで書かれています。 新版は近い将来生まれるかもしれません、使用されるメソッドの徹底的なレビューの後に、と誤りのセットがチェックしました、そして、或るものは修理を悩まします(特に、ddt-xferのPerlバージョンは予想されます)。 その間に、最新版は ftp://ns.dns.pt/pub/dns/ddt-2.0.1.tar.gz から利用可能です。

2.6. The Checker Project

2.6. 数奇のプロジェクト

   The problem of the huge amount of DNS traffic over the Internet is
   getting researchers close attention for quite some time, mainly
   because most of it is unnecessary.  Observations have shown that DNS
   consumes something like twenty times more bandwidth than it should
   [4].  Some causes for this undoubtedly catastrophic scenario lie on
   deficient resolver and name server implementations spread all over
   the world, from personal to super-computers, running all sorts of
   operating systems.

インターネットの上のDNSトラフィックの膨大な量の問題は長い間研究者に周到な注意を届けます、主にそれの大部分が不要であるので。 観測は、DNSがそれより20倍多くの帯域幅は[4]を消費するべきであるように何かを消費するのを示しました。 不十分なレゾルバの上にこの確かに壊滅的なシナリオのいくつかの原因がありました、そして、ネームサーバ実装は世界中で広まりました、スーパーコンピュータに個人的で、実行しているいろいろなオペレーティングシステムから。

   While the panacea is yet to be found (claims are made that the latest
   official version of BIND is a great step forward [5]), work has been
   done in order to identify sources of anomalies, as a first approach
   in the search for a solution.  The Checker Project is one such
   effort, developed at the University of Southern California [6].  It
   consists of a set of C code patched into BIND's named, for monitoring
   server activity, building a database with the history of that
   operation (queries and responses).  It is then possible to generate
   reports from the database summarizing activity and identifying
   behavioral patterns from client requests, looking for anomalies.  The
   named code alteration is small and simple unless you want do have PEC
   checking enabled (see below).  You may find sources and documentation
   at ftp://catarina.usc.edu/pub/checker.

まだ探していて、万能薬はそうです。(BINDの最新の公式のバージョンがすばらしい前進[5])であるというクレームをして、例外の源を特定するために仕事をしました、ソリューションの検索における最初のアプローチとして。 Checker Projectは南カリフォルニア[6]大学で開発されたそのような取り組みの1つです。 それは指定されたBINDのものにパッチされた1セットのCコードから成ります、モニターサーバ活動のために、その操作(質問と応答)の歴史に伴うデータベースを築き上げて。 次に、クライアント要求から活動をまとめて、行動形態を特定するデータベースからのレポートを作るのは可能です、例外を探して。 欲しくないなら、命名されたコード変更は、小さくて、簡単です。可能にされて、チェックしながら、PECを持ってください(以下を見てください)。 あなたは ftp://catarina.usc.edu/pub/checker でソースとドキュメンテーションを見つけることができます。

   Checker only does this kind of collection and reporting, it does not
   try to enforce any rules on the administrators of the defective sites
   by any means whatsoever.  Authors hope that the simple exhibition of
   the evidences is a reason strong enough for those administrators to
   have their problems fixed.

数奇はこの種類の収集と報告をするだけであり、それは全くどんな規則にも欠陥部位の管理者になんとか押しつけようとしません。作者は、証拠の簡単な展示会がそれらの管理者が彼らの問題を修正させることができるくらい強い理由であることを望んでいます。

   An interesting feature is PEC (proactive error checking): the server
   pretends to be unresponsive for some queries by randomly choosing
   some name and start refusing replies for queries on that name during
   a pre-determined period.  Those queries are recorded, though, to try

おもしろい特徴はPEC(先を見越す誤りがチェックして)です: サーバは、手当たりしだいに何らかの名前を選ぶのによるいくつかの質問のための無反応であり、予定された期間、その名前で質問のための回答を拒否し始めるふりをします。 もっとも、それらの質問は、試みるために記録されます。

Romao                                                           [Page 8]

RFC 1713                Tools for DNS debugging            November 1994

1994年11月をデバッグするDNSのためのロマン[8ページ]RFC1713Tools

   to reason about the retry and timeout schemes used by name servers
   and resolvers.  It is expected that properly implemented clients will
   choose another name server to query, while defective ones will keep
   on trying with the same server.  This feature seems to be still under
   testing as it is not completely clear yet how to interpret the
   results.  A PEC-only error checker is available from USC that is much
   simpler than the full error checker.  It examines another name server
   client every 30 minutes to see if this client causes excessive load.

ネームサーバとレゾルバによって使用された再試行とタイムアウト体系に関して推論するために。 適切に実装しているクライアントが質問する別のネームサーバを選ぶと予想されます、欠陥があるものは、同じサーバで試み続けるでしょうが。この特徴はどのように結果を解釈するかが完全にまだ明確であるというわけではないのでまだテストしている下にあるように思えます。 PECだけ誤り市松模様は完全な誤り市松模様よりはるかに簡単なUSCから手があいています。 それは、30分毎にこのクライアントが負担過重を引き起こすかどうか確認するために別のネームサーバクライアントを調べます。

   Presently Checker has been running on a secondary for the US domain
   for more than a year with little trouble.  Authors feel confident it
   should run on any BSD platform (at least SunOS) without problems, and
   is planned to be included as part of the BIND name server.

現在の、Checkerは1年間以上少ない問題で米国ドメインへ2番目で走っています。 それが問題なしでどんなBSDプラットホーム(少なくともSunOS)でも走るべきであり、BINDネームサーバの一部として含まれるように計画されていると確信していると作者は感じます。

   Checker is part of a research project lead by Peter Danzig from USC,
   aimed to implement probabilistic error checking mechanisms like PEC
   on distributed systems [7].  DNS is one such system and it was chosen
   as the platform for testing the validity of these techniques over the
   NSFnet.  It is hoped to achieve enough knowledge to provide means to
   improve performance and reliability of distributed systems.
   Anomalies like undetected server failures, query loops, bad
   retransmission backoff algorithms, misconfigurations and resubmission
   of requests after negative replies are some of the targets for these
   checkers to detect.

数奇は分散システム[7]のPECのようなメカニズムをチェックする確率的な誤りを実装するために目的とされたUSCからのピーター・ダンツィグによる研究計画リードの一部です。 DNSはそのようなシステムの1つです、そして、それはNSFnetの上でこれらのテクニックの正当性をテストするためのプラットホームとして選ばれました。 非検出されるように分散システム例外の性能と信頼性を向上させる手段を提供できるくらいの知識を達成するために、否定的な返事の後の要求のサーバ失敗、質問輪、悪いretransmission backoffアルゴリズム、misconfigurations、および再服従がこれらの市松模様が検出する目標のいくつかであることが望まれています。

2.7. Others

2.7. 他のもの

   All the tools described above are the result of systematic work on
   the issue of DNS debugging, some of them included in research
   projects.  For the sake of completeness several other programs are
   mentioned here.  These, though just as serious, seem to have been
   developed in a somewhat ad-hoc fashion, without an implicit intention
   of being used outside the environments where they were born.  This
   impression is, of course, arguable, nevertheless there was no
   necessity of dedicating an entire section to any of them.  This
   doesn't mean they are not valuable contributions, in some cases they
   may be just what you are looking for, without having to install a
   complete package to do some testings on your domain.

上で説明されたすべてのツールがDNSデバッグの問題に対する系統的な仕事の結果です、研究計画に彼らの何人かを含んでいて。 他の完全を期すために数個のプログラムがここに言及されます。 ちょうど同じくらい重大ですが、これらはいくらか臨時のファッションで開発されたように思えます、彼らが生まれた環境の外に使用されるという暗黙の意志なしで。 この印象がもちろん疑わしい、それにもかかわらず、全体のセクションをそれらのどれかに捧げるという必要は全くありませんでした。 これは、それらが有価約因でないことを意味しないで、いくつかの場合、それらはちょうどあなたが探しているものであるかもしれません、あなたのドメインのいくつかの実験をするために完全なパッケージをインストールする必要はなくて。

   The reference taken was the contrib directory in the latest BIND
   distribution (where some of the above programs can also be found).
   There you will find tools for creating your DNS configuration files
   and NIS maps from /etc/hosts and vice-versa or generate PTR from A
   records (these things may be important as a means of avoiding common
   typing errors and inconsistencies between those tables), syntax
   checkers for zone files, programs for querying and monitoring name
   servers, all the small programs presented in [8], and more.  It is
   worth spending some time looking at them, maybe you'll find that

取られた参照は最新のBIND分配(またいくつかの上記のプログラムを見つけることができるところ)でcontribディレクトリでした。 そこでは、あなたは、あなたのDNS構成ファイルとNIS地図を作成するために/etc/hostsからツールを逆もまた同様に見つけるか、またはA記録(これらのものはそれらのテーブルの間の一般的なタイプ・ミスと矛盾を避ける手段として重要であるかもしれない)、ゾーンファイルのためのシンタクスチェッカ、ネームサーバを質問して、モニターするためのプログラム、[8]に提示された、すべての小さいプログラム、およびその他からPTRを生成するでしょう。 いつかそれらを見ながら費やす価値がある、多分、あなたはそれを見つけるでしょう。

Romao                                                           [Page 9]

RFC 1713                Tools for DNS debugging            November 1994

1994年11月をデバッグするDNSのためのロマン[9ページ]RFC1713Tools

   program you were planning to write yourself.  The latest public
   version of BIND can be found at
   ftp://gatekeeper.dec.com/pub/misc/vixie/4.9.2-940221.tar.gz.  As of
   this writing BIND-4.9.3 is in its final beta stages and a public
   release is expected soon, also at gatekeeper.dec.com.

計画が自分に書くつもりであったなら、プログラムしてください。 ftp://gatekeeper.dec.com/pub/misc/vixie/4.9.2-940221.tar.gz でBINDの最新の公共のバージョンを見つけることができます。 この書くこと現在、BIND-4.9.3は最終的なベータ段階でそうです、そして、公共のリリースはすぐ予想されます、gatekeeper.dec. comでも。

   You may also want to consider using a version control system like
   SCCS or RCS to maintain your configuration files consistent through
   updates, or use tools like M4 macros to generate those files.  As
   stated above, it's important to avoid human-generated errors,
   creating problems that are difficult to track down, since they're
   often hidden behind some mistyped name.  Errors like this may end up
   in many queries for a non-existing name, just to mention the less
   serious kind.  See [9] for a description of the most common errors
   made while configuring domains.

あなたは、アップデートで一貫しているのにあなたの構成ファイルを維持するためにSCCSやRCSのようなバージョン管理システムを使用すると考えたいか、またはまた、それらのファイルを生成するのにM4マクロのようなツールを使用したがっているかもしれません。 上に述べられているように、人間が発生している誤りを避けるのは重要です、捜し出すのが難しい問題を生じさせて、それらが何らかのmistyped名前の後ろにしばしば隠されるので。 このような誤りは、ただそれほど重大でない種類について言及するために非既存の名前のための多くの質問で終わるかもしれません。 ドメインを構成している間、最も一般的な誤りの記述のための[9]が作られているのを見てください。

3. Why look after DNS?

3. なぜDNSの世話をしますか?

   Several pieces of software were presented to help people administer
   and debug their name services.  They exhibit many differences in
   their way of doing things, scope and requirements and it may be
   difficult just to choose one of them to work with.  For one thing,
   people's expectations from these tools vary according to their kind
   of involvement with DNS.  If you are responsible for a big domain,
   e.g., a top-level one or a big institution with many hosts and sub-
   domains, you probably want to see how well is the tree below your
   node organized, since the consequences of errors tend to propagate
   upwards, thus affecting your own domain and servers.  For that you
   need some program that recursively descends the domain tree and
   analyzes each domain per se and the interdependencies between them
   all.  You will have to consider how deep you want your analysis to
   be, the effects it will have on the network infrastructure, i.e.,
   will it generate traffic only inside a campus network, no matter how
   big it is, or will it be spread over, say, a whole country (of
   course, your kind of connectivity plays an important role here).

数片のソフトウェアは、人々が彼らの名前サービスを管理して、デバッグするのを助けるために提示されました。 彼らはことをするのにおいて、まさしくそれらの1つを選ぶのが難しいかもしれない働いている自分達の方法で多くの違いを示します。 一つには、それらのDNSへのかかわり合いの種類に従って、これらのツールからの人々の期待は異なります。 多くのホストとサブドメインで大きいドメイン、例えば、トップレベル1か大きい団体に責任があるなら、あなたは、たぶん誤りの結果が、上向きに伝播する傾向があるのでまとめられたあなたのノードの下の木であり、その結果、あなた自身のドメインとサーバに影響しながら、どれくらいよく見たがっているか。 それのために、あなたはドメイン木を再帰的に滑降させて、そういうものとして各ドメインを分析するあるプログラムとそれらのすべての間の相互依存性を必要とします。 それはたとえば、全の国にわたってあなたは、あなたの分析がどれくらい深くしたいかを考えなければならないでしょう、それがネットワークインフラに持っている効果か、すなわち、どんなに大きくても、キャンパスネットワークだけの中でトラフィックを生成するだろうか、普及になるでしょうか?(もちろん、あなたの接続性の種類はここで重要な役割を果たします)

   You may simply want to perform some sanity checks on your own domain,
   without any further concerns.  Or you may want to participate in some
   kind of global effort to monitor name server traffic, either for
   research purposes or just to point out the "trouble-queries" that
   flow around.

あなたは少しもさらなる関心なしであなた自身のドメインにいくつかの健全度チェックを単に実行したがっているかもしれません。 または、あなたは、どちらか研究目的のためにネームサーバトラフィックをモニターするか、またはただ流れるおよそ問題「質問」を指摘するためにある種のグローバルな取り組みに参加したがっているかもしれません。

   Whatever your interest may be, you can almost surely find a tool to
   suit it.  Eliminating problems like those described in this document
   is a major contribution for the efficiency of an important piece of
   the Internet mechanism.  Just to have an idea of this importance,
   think of all the applications that depend on it, not just to get
   addresses out of names.  Many systems rely on DNS to store, retrieve

あなたの利益のためが何であっても、あなたは、それに合うようにほぼ確実にツールを見つけることができます。 それらのような問題が説明した排泄は本書ではインターネットメカニズムの重要な片の効率のための主要な貢献です。 ただこの重要性の考えを持つために、それによるすべてのアプリケーションを考えてください、名前からアドレスを得るには、正当ではありません。 多くのシステムがDNSを店を当てにする、検索

Romao                                                          [Page 10]

RFC 1713                Tools for DNS debugging            November 1994

1994年11月をデバッグするDNSのためのロマン[10ページ]RFC1713Tools

   and spread the information they need: Internet electronic mail was
   already mentioned (see [10] for details) and work is in progress to
   integrate X.400 operations with DNS [11]; others include "remote
   printing" services [12], distributed file systems and network routing
   purposes, among others.  These features may be accomplished by some
   standard, well-known resource records [13], or by new, experimental
   ones [14, 15].  Even if some of them won't succeed, one may well
   expect some more load on the DNS burden.

そして、彼らが必要とする情報を広げてください: インターネット電子メールは既に言及されました、そして、(詳細のための[10]を見てください)仕事はX.400操作をDNS[11]と統合するために進行しています。 他のものは特に「リモート印刷」サービス[12]、分散ファイルシステム、およびネットワークルーティング目的を入れます。 これらの特徴はいくつかの標準の、そして、よく知られるリソース記録[13]、または新しくて、実験的なもの[14、15]によって達成されるかもしれません。 彼らの何人かが成功しないでも、人はたぶんDNS負担の上のそれ以上の負荷を期待するでしょう。

   The ubiquitous DNS thus deserves a great deal of attention, perhaps
   much more than it generally has.  One may say that it is a victim of
   its own success: if a user triggers an excessive amount of queries
   only to have one request satisfied, he won't worry about it (in fact,
   he won't notice it), won't complain to his system administrator, and
   things will just go on like this.  Of course, DNS was designed to
   resist and provide its services despite all these anomalies.  But by
   doing so it is frequently forgotten, as long as people can Telnet or
   ftp.  As DNS will be given new responsibilities, as pointed in the
   above paragraph, the problems described in this text will grow more
   serious and new ones may appear (notably security ones [16], with a
   lot of work being presently in progress addressing security in DNS),
   if nothing is done to purge them.

その結果、遍在しているDNSは大きな注意に恐らく一般に、そうするよりはるかに値します。 それがそれ自身の成功の犠牲者であると言うかもしれません: ユーザが1つの要望を応じさせているためには唯一の質問の過量の引き金となると、彼は、それを心配しないで(事実上、彼はそれに気付かないでしょう)、また彼のシステム管理者に不平を言って、これが好きでないでしょういろいろなことが、ただ先へ進む。 もちろん、DNSは、サービスに抵抗して、これらのすべての例外にもかかわらず、提供するように設計されました。 しかし、そうすることによって、それは人々はTelnetかftpをそうすることができるのと同じくらい長い間、頻繁に忘れられています。 新しい責任をDNSに与えるのに従って、本稿で説明された問題は前の段落で指されるように悪化するでしょう、そして、新しい(著しく現在、DNSでセキュリティを扱う進行中にはある多くの仕事があるセキュリティもの[16])に見えるかもしれません、彼らを掃除するために何もしないなら。

References

参照

   [1] Lottor, M., "Internet Domain Survey, October 1994",
       http://www.nw.com/zone/WWW/report.html, October 1994.

[1] 1994年10月、Lottor M.、「インターネットドメイン調査、1994年10月」 http://www.nw.com/zone/WWW/report.html 。

   [2] Beecher, B., "Dealing With Lame Delegations", Univ. Michigan,
       LISA VI, October 1992.

[2] B. ビーチャー、「不十分な委譲に対処すること」での大学 ミシガン、リサVI、1992年10月。

   [3] Frazao, J. and J. L. Martins, "Ddt - Domain Debug Tools, A
       Package to Debug the DNS Tree", Dept. Informatica Faculdade
       Ciencias Univ. Lisboa, DI-FCUL-1992-04, January 1992.

[3] Frazao、J.、およびJ.L.マーティンズ、「Ddt--ドメインデバッグツール、AはDNS木をデバッグにパッケージする」、部 Informatica Faculdade Ciencias大学 リスボア、ディ-FCUL-1992-04、1992年1月。

   [4] Danzig, P., "Probabilistic Error Checkers: Fixing DNS", Univ.
       Southern California, Technical Report, February 1992.

[4] ダンツィグ、P.、「確率的な誤りは以下が数奇です」。 「DNSを修理します」、大学 南カリフォルニア、技術報告書、1992年2月。

   [5] Kumar, A., J. Postel, C. Neuman, P. Danzig and S. Miller, "Common
       DNS Implementation Errors and Suggested Fixes", RFC 1536,
       USC/Information Sciences Institute, October 1993.

クマーとA.とJ.ポステルとC.ヌーマンとP.ダンツィグとS.ミラー、「一般的なDNS実装誤りの、そして、提案されたフィックス」、RFC1536、USC/情報科学が1993年10月に設ける[5]。

   [6] Miller, S. and P. Danzig, "The Checker Project, Installation and
       Operator's Manual", Univ. Southern California, TR CS94-560, 1994.

[6] ミラーとS.とP.ダンツィグ、「数奇のプロジェクト、インストール、およびオペレータのマニュアル」大学 南カリフォルニア、TR CS94-560、1994。

   [7] Danzig, P., K. Obraczka and A. Kumar, "An Analisys of Wide-Area
       Name Server Traffic", Univ. Southern California, TR 92-504, 1992.

[7] ダンツィグとP.とK.ObraczkaとA.クマー、「広い領域ネームサーバトラフィックのAnalisys」大学 南カリフォルニア、TR92-504、1992。

Romao                                                          [Page 11]

RFC 1713                Tools for DNS debugging            November 1994

1994年11月をデバッグするDNSのためのロマン[11ページ]RFC1713Tools

   [8] Albitz, P. and C. Liu, "DNS and BIND", O'Reilly and Associates
       Inc., October 1992.

[8]Albitz、P.、C.リュウ、および「DNSとひも」、オライリーと仲間株式会社、10月1992日

   [9] Beertema, P., "Common DNS Data File Configuration Errors", RFC
       1537, CWI, October 1993.

[9]Beertema、P.、「一般的なDNSデータファイル構成誤り」、RFC1537、CWI、1993年10月。

  [10] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
       974, CSNET CIC BBN Laboratories Inc., January 1986.

[10] ヤマウズラと、C.と、「メールルート設定とドメインシステム」、STD14、RFC974、CSNET CIC BBN研究所株式会社、1月1986日

  [11] Allocchio, C., A. Bonito, B. Cole, S. Giordano and R. Hagens,
       "Using the Internet DNS to Distribute RFC1327 Mail Address
       Mapping Tables", RFC 1664, GARR, Cisco Systems Inc., Centro
       Svizzero Calcolo Scientifico, ANS, August 1994.

[11]Allocchio、C.、A.かつお、B.コール、S.ジョルダーノ、およびR.Hagens、「RFC1327を分配するのにインターネットDNSを使用して、アドレス変換テーブルを郵送してください」、RFC1664、ガー、シスコシステムズ株式会社、セントロSvizzero Calcolo Scientifico、ANS、1994年8月。

  [12] Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT
       Subdomain: General Principles and Policy", RFC 1530, Internet
       Multicasting Service, Dover Beach Consulting Inc., October 1993.

[12] マラマッド、C.、およびM.が上昇した、「TPC.INTサブドメインのための操作のプリンシプルズ:」 「RFC1530、インターネット同報通信、ドーヴァービーチが株式会社に相談することでの10月1993日綱領と方針」

  [13] Rosenbaum, R., "Using the Domain Name System to Store Arbitrary
       String Attributes", RFC 1464, Digital Equipment Corporation, May
       1993.

[13] ローゼンボム、R.が「任意のストリング属性を保存するのにドメインネームシステムを使用し」て、RFC1464(DEC)は1993を使用します。

  [14] Everhart, C., L. Mamakos, R. Ullmann and P. Mockapetris (Ed.),
       "New DNS RR Definitions", RFC 1183, Transarc, Univ. Maryland,
       Prime Computer, Information Sciences Institute, October 1990.

[14] エバーハートとC.、L.MamakosとR.ウルマンとP.Mockapetris編、「新しいDNS RR定義」、RFC1183、Transarc、大学 メリーランド、プライムコンピュータ、科学が1990年10月に設ける情報。

  [15] Manning, B., and R. Colella, "DNS NSAP Resource Records", RFC
       1706, USC/Information Sciences Institute, NIST, October 1994.

[15] マニング、B.とR.Colella、「DNS NSAPリソース記録」、RFC1706、科学が設けるUSC/情報、NIST、1994年10月。

  [16] Gavron, E., "A Security Problem and Proposed Correction With
       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
       October 1993

[16] Gavronと、E.と、「広く配布しているDNSソフトウェアとの警備上の問題と提案された修正」(RFC1535)は研究株式会社を負かします、1993年10月

Romao                                                          [Page 12]

RFC 1713                Tools for DNS debugging            November 1994

1994年11月をデバッグするDNSのためのロマン[12ページ]RFC1713Tools

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo (although security is
   briefly mentioned at the end of section 3).

このメモで安全保障問題について議論しません(セキュリティは簡潔にセクション3の端に言及されますが)。

Author's Address

作者のアドレス

   Artur Romao
   DI - Faculdade de Ciencias e Tecnologia
   Universidade Nova de Lisboa
   Quinta da Torre
   P-2825 Monte de Caparica
   Portugal

アルツールロマンDI--Faculdade de Ciencias e Tecnologia Universidade Nova deリスボアQuinta daトーレ・P-2825 Monte deカパリカポルトガル

   Phone: +351 1 294 28 44
   Fax:   +351 1 295 77 86
   EMail: artur@fct.unl.pt

以下に電話をしてください。 +351 1 294、28 44、Fax: +351 1 295 77 86はメールされます: artur@fct.unl.pt

Romao                                                          [Page 13]

ロマン[13ページ]