RFC1912 日本語訳

Network Working Group                                            D. Barr
Request for Comments: 1912             The Pennsylvania State University
Obsoletes: 1537                                            February 1996
Category: Informational

コメントを求めるワーキンググループD.バール要求をネットワークでつないでください: 1912 ペンシルバニア州立大学は以下を時代遅れにします。 1537 1996年2月のカテゴリ: 情報

            Common DNS Operational and Configuration Errors

一般的な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

要約

   This memo describes errors often found in both the operation of
   Domain Name System (DNS) servers, and in the data that these DNS
   servers contain.  This memo tries to summarize current Internet
   requirements as well as common practice in the operation and
   configuration of the DNS.  This memo also tries to summarize or
   expand upon issues raised in [RFC 1537].

このメモは両方でのドメインネームシステム(DNS)サーバの操作がしばしば見つけられて、これらのDNSサーバが含むデータでそうする誤りについて説明します。 このメモはDNSの操作と構成における一般的な習慣と同様に現在のインターネット要件をまとめようとします。 このメモは、[RFC1537]で提起された問題では、まとめようとするか、またはまた、広がろうとします。

1. Introduction

1. 序論

   Running a nameserver is not a trivial task.  There are many things
   that can go wrong, and many decisions have to be made about what data
   to put in the DNS and how to set up servers.  This memo attempts to
   address many of the common mistakes and pitfalls that are made in DNS
   data as well as in the operation of nameservers.  Discussions are
   also made regarding some other relevant issues such as server or
   resolver bugs, and a few political issues with respect to the
   operation of DNS on the Internet.

ネームサーバを実行するのは、些細なタスクではありません。 支障をきたすことができる多くのものがあります、そして、どんなデータに関してDNSとどうサーバをセットアップするかを入れるのを多くの決定をしなければならないか。 このメモは、DNSデータとネームサーバの操作で作られている一般的な誤りと落とし穴の多くを扱うのを試みます。 また、サーバかレゾルババグなどのある他の当該の問題、およびインターネットにおけるDNSの操作に関するいくつかの政治問題に関して議論をします。

2. DNS Data

2. DNSデータ

   This section discusses problems people typically have with the DNS
   data in their nameserver, as found in the zone data files that the
   nameserver loads into memory.

このセクションは問題の人々について論じます。DNSと共にそれらのネームサーバにおけるデータを通常持ってください、ネームサーバがメモリにロードするゾーンデータファイルで見つけられるように。

2.1 Inconsistent, Missing, or Bad Data

2.1 矛盾したか、なくなったか、悪いデータ

   Every Internet-reachable host should have a name.  The consequences
   of this are becoming more and more obvious.  Many services available
   on the Internet will not talk to you if you aren't correctly
   registered in the DNS.

すべてのインターネット届いているホストには、名前があるべきです。 この結果はますます明白になっています。 あなたがDNSに正しく登録されないなら、インターネットで利用可能な多くのサービスはあなたと話さないでしょう。

Barr                         Informational                      [Page 1]

RFC 1912                   Common DNS Errors               February 1996

一般的な[1ページ]RFC1912DNS誤り1996年2月の情報のバール

   Make sure your PTR and A records match.  For every IP address, there
   should be a matching PTR record in the in-addr.arpa domain.  If a
   host is multi-homed, (more than one IP address) make sure that all IP
   addresses have a corresponding PTR record (not just the first one).
   Failure to have matching PTR and A records can cause loss of Internet
   services similar to not being registered in the DNS at all.  Also,
   PTR records must point back to a valid A record, not a alias defined
   by a CNAME.  It is highly recommended that you use some software
   which automates this checking, or generate your DNS data from a
   database which automatically creates consistent data.

あなたのPTRとA記録が合っているのを確実にしてください。 あらゆるIPアドレスのために、合っているPTR記録がaddr.arpaのドメインにあるべきです。 ホストがそうである、マルチ、家へ帰り、(1つ以上のIPアドレス) 対応するPTRがすべてのIPアドレスで(最初のものであるだけではない)を記録するのを確実にしてください。 合っているPTRとA記録を持っていない場合、全くDNSに登録されないのと同様のインターネットのサービスの損失を引き起こす場合があります。 また、PTR記録はCNAMEによって定義された別名ではなく、有効なA記録を示さなければなりません。 あなたが、この照合を自動化する何らかのソフトウェアを使用するか、またはあなたのDNSが自動的に一貫したデータを作成するデータベースからのデータであると生成するのが、非常にお勧めです。

   DNS domain names consist of "labels" separated by single dots.  The
   DNS is very liberal in its rules for the allowable characters in a
   domain name.  However, if a domain name is used to name a host, it
   should follow rules restricting host names.  Further if a name is
   used for mail, it must follow the naming rules for names in mail
   addresses.

DNSドメイン名はただ一つのドットによって切り離された「ラベル」から成ります。 ドメイン名における許容できるキャラクタに、DNSは規則で非常に寛容です。 しかしながら、ドメイン名がホストを任命するのに使用されるなら、それはホスト名を制限する規則に従うべきです。 より遠くに、名前がメールに使用されるならそれは郵便の宛先の名前のための命名規則に従わなければなりません。

   Allowable characters in a label for a host name are only ASCII
   letters, digits, and the `-' character.  Labels may not be all
   numbers, but may have a leading digit  (e.g., 3com.com).  Labels must
   end and begin only with a letter or digit.  See [RFC 1035] and [RFC
   1123].  (Labels were initially restricted in [RFC 1035] to start with
   a letter, and some older hosts still reportedly have problems with
   the relaxation in [RFC 1123].)  Note there are some Internet
   hostnames which violate this rule (411.org, 1776.com).  The presence
   of underscores in a label is allowed in [RFC 1033], except [RFC 1033]
   is informational only and was not defining a standard.  There is at
   least one popular TCP/IP implementation which currently refuses to
   talk to hosts named with underscores in them.  It must be noted that
   the language in [1035] is such that these rules are voluntary -- they
   are there for those who wish to minimize problems.  Note that the
   rules for Internet host names also apply to hosts and addresses used
   in SMTP (See RFC 821).

ホスト名のためのラベルの許容できる唯一のキャラクタは、ASCII手紙と、ケタと、'--'キャラクタです。 ラベルには、数でないかもしれませんが、主なケタ(例えば、3com.com)があるかもしれません。 ラベルは、単に手紙かケタで終わって、始まらなければなりません。 [RFC1035]と[RFC1123]を見てください。 (何人かの、より年取ったホストには、ラベルは初めは、手紙から始まるように[RFC1035]で制限されて、伝えられるところによれば、[RFC1123]の緩和に関する問題がまだあります。) この規則(411.org、1776.com)に違反するいくつかのインターネットホスト名があることに注意してください。 そして、ラベルでの強調の存在が[RFC1033]に許容されていて、[RFC1033]が情報である、唯一、規格を定義していませんでした。 現在それらで強調で指定されたホストと話すのを拒否する少なくとも1つのポピュラーなTCP/IP実装があります。 これらの規則が[1035]の言語がそのようなものであるので自発的であることに注意しなければなりません--それらは問題を最小にしたがっている人のためにそこにあります。また、インターネットホスト名のための規則がSMTPで使用されるホストとアドレスに適用されることに注意してください(RFC821を見てください)。

   If a domain name is to be used for mail (not involving SMTP), it must
   follow the rules for mail in [RFC 822], which is actually more
   liberal than the above rules.  Labels for mail can be any ASCII
   character except "specials", control characters, and whitespace
   characters.  "Specials" are specific symbols used in the parsing of
   addresses.  They are the characters "()<>@,;:\".[]".  (The "!"
   character wasn't in [RFC 822], however it also shouldn't be used due
   to the conflict with UUCP mail as defined in RFC 976)  However, since
   today almost all names which are used for mail on the Internet are
   also names used for hostnames, one rarely sees addresses using these
   relaxed standard, but mail software should be made liberal and robust
   enough to accept them.

それはドメイン名がメールに使用される(SMTPにかかわらないで)ことであるなら、[RFC822]のメールのために約束を守らなければなりません。(]は実際に上の規則より寛容です)。 メールのためのラベルは「特別番組」、制御文字、および空白キャラクタ以外のどんなASCII文字であるかもしれません。 「特別番組」はアドレスの構文解析に使用される特定のシンボルです。 それらはキャラクタ「() <>@; : \".[]"」です。 (“!"キャラクタが[RFC822]にありませんでした、しかしながら、また、UUCPメールとの闘争のためRFC976で定義されるようにそれを使用するべきではありません) しかしながら、今日のインターネットに関するメールに使用されるほとんどすべての名前がまた、ホスト名に使用される名前であるので、人は標準でリラックスするこれらを使用することでアドレスをめったに見ませんが、メールソフトウェアをそれらを受け入れるほど寛容で強健にするべきです。

Barr                         Informational                      [Page 2]

RFC 1912                   Common DNS Errors               February 1996

一般的な[2ページ]RFC1912DNS誤り1996年2月の情報のバール

   You should also be careful to not have addresses which are valid
   alternate syntaxes to the inet_ntoa() library call.  For example 0xe
   is a valid name, but if you were to type "telnet 0xe", it would try
   to connect to IP address 0.0.0.14.  It is also rumored that there
   exists some broken inet_ntoa() routines that treat an address like
   x400 as an IP address.

また、あなたもinet_ntoa()ライブラリ呼び出しに有効な代替の構文であるアドレスを持っていないのに慎重であるはずです。 例えば、0xeが妥当な名前ですが、あなたが「telnet0xe」をタイプするなら、IPアドレスに接続しようとする、0.0、.0、.14 また、IPアドレスとしてx400のようなアドレスを扱ういくつかの中断したinet_ntoa()ルーチンが存在すると噂されています。

   Certain operating systems have limitations on the length of their own
   hostname.  While not strictly of issue to the DNS, you should be
   aware of your operating system's length limits before choosing the
   name of a host.

あるオペレーティングシステムはそれら自身のホスト名の長さに制限を持っています。 ホストの名前を選ぶ前に、DNSへの問題では、あなたは厳密でなくあなたのオペレーティングシステムの長さの限界を知るべきですが。

   Remember that many resource records (abbreviated RR) take on more
   than one argument.  HINFO requires two arguments, as does RP.  If you
   don't supply enough arguments, servers sometime return garbage for
   the missing fields.  If you need to include whitespace within any
   data, you must put the string in quotes.

多くのリソース記録(RRを簡略化する)が1つ以上の議論を帯びるのを覚えていてください。 HINFOはRPのように2つの議論を必要とします。 あなたが十分な議論を供給しないなら、取り逃がすいつかのリターンゴミがさばくサーバです。 どんなデータの中にも空白を含む必要があるなら、あなたは引用文にストリングを入れなければなりません。

2.2 SOA records

2.2 SOA記録

   In the SOA record of every zone, remember to fill in the e-mail
   address that will get to the person who maintains the DNS at your
   site (commonly referred to as "hostmaster").  The `@' in the e-mail
   must be replaced by a `.' first.  Do not try to put an `@' sign in
   this address.  If the local part of the address already contains a
   `.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by
   preceding it with `\' character.  (e.g., to become
   John\.Smith.widget.xx) Alternately (and preferred), you can just use
   the generic name `hostmaster', and use a mail alias to redirect it to
   the appropriate persons.  There exists software which uses this field
   to automatically generate the e-mail address for the zone contact.
   This software will break if this field is improperly formatted.  It
   is imperative that this address get to one or more real persons,
   because it is often used for everything from reporting bad DNS data
   to reporting security incidents.

あらゆるゾーンに関するSOA記録では、忘れずにあなたのサイト(一般的に"hostmaster"と呼ばれる)でDNSを維持する人に着くEメールアドレスに記入してください。 'メールによる'@'を'.'第1に取り替えなければなりません。 '@'サインをこのアドレスに入れようとしないでください。 'アドレスの地方の部分は既にa'を含んでいる'(例えば、 John.Smith@widget.xx )、次に、あなたは、'. ''\でそれに先行する'キャラクタを引用する必要があります。 (例えばジョン\.Smith.widget.xxになる) 交互に(そして、好まれる)、あなたは、ただ総称'hostmaster'を使用して、適切な人々にそれを向け直すのに通称メールを使用できます。 自動的にゾーン接触のためのEメールアドレスを生成するのにこの分野を使用するソフトウェアが存在しています。 この分野が不適切にフォーマットされると、このソフトウェアが知れ渡るでしょう。 このアドレスが1人以上の実在の人物に着くのは、必須です、それが悪いDNSデータをセキュリティインシデントを報告するのに報告するのですべてにしばしば使用されるので。

   Even though some BIND versions allow you to use a decimal in a serial
   number, don't.  A decimal serial number is converted to an unsigned
   32-bit integer internally anyway.  The formula for a n.m serial
   number is n*10^(3+int(0.9+log10(m))) + m which translates to
   something rather unexpected.  For example it's routinely possible
   with a decimal serial number (perhaps automatically generated by
   SCCS) to be incremented such that it is numerically larger, but after
   the above conversion yield a serial number which is LOWER than
   before.  Decimal serial numbers have been officially deprecated in
   recent BIND versions.  The recommended syntax is YYYYMMDDnn
   (YYYY=year, MM=month, DD=day, nn=revision number.  This won't
   overflow until the year 4294.

通し番号でいくつかのBINDバージョンで小数を使用できますが、しないでください。 10進通し番号は未署名の32ビットの整数に内部的にとにかく変えられます。 3+はintされます。n.m通し番号のための公式がn*10^である、((かなり予期していなかった何かに翻訳される0.9+log10(m)))+m。 例えば、増加されるのが10進通し番号できまりきって可能であるので(恐らくSCCSによって自動的に生成された)、それは以前より数の上で大きいのですが、上の変換の後に、LOWERである通し番号をもたらしてください。 10進通し番号は最近のBINDバージョンで公式に推奨しないです。 お勧めの構文はYYYYMMDDnnです。YYYYは年、MM=月等しく、DDは日、nn=revision numberと等しいです。(これは4294年まであふれないでしょう。

Barr                         Informational                      [Page 3]

RFC 1912                   Common DNS Errors               February 1996

一般的な[3ページ]RFC1912DNS誤り1996年2月の情報のバール

   Choose logical values for the timer values in the SOA record (note
   values below must be expressed as seconds in the zone data):

SOA記録のタイマ値のための論理的な値を選んでください(ゾーンデータの秒として以下の注意値を言い表さなければなりません):

      Refresh: How often a secondary will poll the primary server to see
          if the serial number for the zone has increased (so it knows
          to request a new copy of the data for the zone).  Set this to
          how long your secondaries can comfortably contain out-of-date
          data.  You can keep it short (20 mins to 2 hours) if you
          aren't worried about a small increase in bandwidth used, or
          longer (2-12 hours) if your Internet connection is slow or is
          started on demand.  Recent BIND versions (4.9.3) have optional
          code to automatically notify secondaries that data has
          changed, allowing you to set this TTL to a long value (one
          day, or more).

リフレッシュします: 2番目は、ゾーンのための通し番号が増加したかどうか(したがって、それはゾーンのためのデータの新しいコピーを要求するのを知っています)確認するためにどれくらいの頻度でプライマリサーバに投票するでしょうか? 代理人がどれくらい長い間ゆったり時代遅れなデータを含むことができるかにこれを設定してください。 あなたは、あなたが微増が心配でないなら使用される帯域幅で短く(2時間までの20mins)それを保つか、またはあなたのインターネット接続が遅いか、または要求に応じて始められるなら、より長い間(2〜12時間)、保つことができます。 最近のBINDバージョン、(4.9、.3、)、データが変化したことを自動的に代理人に通知する任意のコードを持ってください、あなたが長い値(1日以上)にこのTTLを設定するのを許容して。

      Retry: If a secondary was unable to contact the primary at the
          last refresh, wait the retry value before trying again.  This
          value isn't as important as others, unless the secondary is on
          a distant network from the primary or the primary is more
          prone to outages.  It's typically some fraction of the refresh
          interval.

以下を再試行してください。 2番目が最終で予備選挙に連絡できなかったなら、リフレッシュしてください、そして、再試行する前に、再試行値を待ってください。 この値は他のものほど重要ではありません、セカンダリが遠方のネットワークで予備選挙から来ているか、または予備選挙が供給停止により傾向がない場合。 通常、それが何らかの断片である、間隔をリフレッシュしてください。

      Expire: How long a secondary will still treat its copy of the zone
          data as valid if it can't contact the primary.  This value
          should be greater than how long a major outage would typically
          last, and must be greater than the minimum and retry
          intervals, to avoid having a secondary expire the data before
          it gets a chance to get a new copy.  After a zone is expired a
          secondary will still continue to try to contact the primary,
          but it will no longer provide nameservice for the zone.  2-4
          weeks are suggested values.

期限が切れます: それでも、予備選挙に連絡できないと、どれくらい長い2番目は有効であるとしてゾーンデータのコピーを扱うでしょうか? この値は、新しいコピーを手に入れる機会を得る前に2番目にデータを吐き出させるのを避けるためにどれくらい長い主要な供給停止が通常続くだろうかより大きいはずであり、最小限と再試行間隔より大きくなければなりません。 ゾーンが満期になった後に、それでも、2番目は、予備選挙に連絡しようとし続けるでしょうが、それはもうnameserviceをゾーンに提供しないでしょう。 2-4 何週間も提案された値です。

      Minimum: The default TTL (time-to-live) for resource records --
          how long data will remain in other nameservers' cache.  ([RFC
          1035] defines this to be the minimum value, but servers seem
          to always implement this as the default value)  This is by far
          the most important timer.  Set this as large as is comfortable
          given how often you update your nameserver.  If you plan to
          make major changes, it's a good idea to turn this value down
          temporarily beforehand.  Then wait the previous minimum value,
          make your changes, verify their correctness, and turn this
          value back up.  1-5 days are typical values.  Remember this
          value can be overridden on individual resource records.

最小限: リソース記録のためのデフォルトTTL(生きる時間)--どれくらい長いままで、データは他のネームサーバのキャッシュに残るでしょうか? ([RFC1035]は最小値になるようにこれを定義しますが、サーバはデフォルト値としていつもこれを実装するように思えます) これは断然最も重要なタイマです。 考えて、快適であるのとこれ同じくらい大きい状態で設定されて、ネームサーバをアップデートしてください。あなたが、大きな変化を作るのを計画しているなら、あらかじめ一時この値を拒絶するのは、名案です。 次に、前の最小値を待ってください、そして、変更を行ってください、そして、それらの正当性について確かめてください、そして、この値を捜しあてて戻してください。 1-5 何日も典型的な値です。 個々のリソース記録でこの値をくつがえすことができたのを覚えていてください。

Barr                         Informational                      [Page 4]

RFC 1912                   Common DNS Errors               February 1996

一般的な[4ページ]RFC1912DNS誤り1996年2月の情報のバール

   As you can see, the typical values above for the timers vary widely.
   Popular documentation like [RFC 1033] recommended a day for the
   minimum TTL, which is now considered too low except for zones with
   data that vary regularly.  Once a DNS stabilizes, values on the order
   of 3 or more days are recommended.  It is also recommended that you
   individually override the TTL on certain RRs which are often
   referenced and don't often change to have very large values (1-2
   weeks).  Good examples of this are the MX, A, and PTR records of your
   mail host(s), the NS records of your zone, and the A records of your
   nameservers.

お分かりのように、タイマにおける、上の典型的な値はばらつきが大きいです。 [RFC1033]のようなポピュラーなドキュメンテーションは1日間、最小のTTLを推薦しました。(TTLは現在、ゾーンを除いて、定期的に異なるデータで低過ぎると考えられます)。 DNSがいったん安定していると、3日間以上の注文の値はお勧めです。 また、あなたが非常に大きい値(1-2週間)を持つために個別にしばしば参照をつけられて、しばしば変化するというわけではないあるRRsの上のTTLをくつがえすのも、お勧めです。 この好例がMX、Aであり、PTRはあなたのメールホストの記録と、あなたのゾーンに関するNS記録と、あなたのネームサーバに関するA記録です。

2.3 Glue A Records

2.3は記録をにかわで接ぎます。

   Glue records are A records that are associated with NS records to
   provide "bootstrapping" information to the nameserver.  For example:

接着剤記録がネームサーバに情報を「独力で進み」ながら提供するNS記録に関連しているA記録である、例えば:

           podunk.xx.      in      ns      ns1.podunk.xx.
                           in      ns      ns2.podunk.xx.
           ns1.podunk.xx.  in      a       1.2.3.4
           ns2.podunk.xx.  in      a       1.2.3.5

podunk.xxナノ秒ns1.podunk.xxでナノ秒、ns2.podunk.xx ns1.podunk.xxコネa1.2.3、.4ns2.podunk.xxコネa1.2.3、.5

   Here, the A records are referred to as "Glue records".

ここに、A記録は「接着剤記録」と呼ばれます。

   Glue records are required only in forward zone files for nameservers
   that are located in the subdomain of the current zone that is being
   delegated.  You shouldn't have any A records in an in-addr.arpa zone
   file (unless you're using RFC 1101-style encoding of subnet masks).

接着剤記録が代表として派遣されている現在のゾーンに関するサブドメインに位置しているネームサーバのための前進のゾーンファイルだけで必要です。 あなたには、addr.arpaのゾーンファイルでのどんなA記録もあるべきではありません(あなたがサブネットマスクのRFCの1101スタイルのコード化を使用していない場合)。

   If your nameserver is multi-homed (has more than one IP address), you
   must list all of its addresses in the glue to avoid cache
   inconsistency due to differing TTL values, causing some lookups to
   not find all addresses for your nameserver.

あなたのネームサーバがそうである、マルチ、家へ帰り、(IPが扱う1つ以上) あなたは異なったTTL値によるキャッシュ矛盾を避けるために接着剤にアドレスのすべてを記載しなければなりません、ルックアップがあなたのネームサーバのためのすべてのアドレスを見つけるというわけではないことをいくつか引き起こして。

   Some people get in the bad habit of putting in a glue record whenever
   they add an NS record "just to make sure".  Having duplicate glue
   records in your zone files just makes it harder when a nameserver
   moves to a new IP address, or is removed. You'll spend hours trying
   to figure out why random people still see the old IP address for some
   host, because someone forgot to change or remove a glue record in
   some other file.  Newer BIND versions will ignore these extra glue
   records in local zone files.

彼らが、NSが「まさしく、確実にする」ために記録すると言い足すときはいつも、接着剤記録を入れる悪習に入る人々もいます。 あなたのゾーンファイルでの写し接着剤記録を持っているのは、ネームサーバが新しいIPアドレスに移行するとただそれをより困難にするか、または移されます。 無作為の人々がなぜホストのためにまだ古いIPアドレスを見ているかを理解しようとするのにあなたは何時間も費やすでしょう、だれかが、ある他のファイルでの接着剤記録を変えるか、または取り除くのを忘れたので。 より新しいBINDバージョンはローカルのゾーンファイルでのこれらの付加的な接着剤記録を無視するでしょう。

   Older BIND versions (4.8.3 and previous) have a problem where it
   inserts these extra glue records in the zone transfer data to
   secondaries.  If one of these glues is wrong, the error can be
   propagated to other nameservers.  If two nameservers are secondaries
   for other zones of each other, it's possible for one to continually
   pass old glue records back to the other.  The only way to get rid of

より古いBINDバージョン、(4.8、.3、前である、)、それがゾーン転送データでのこれらの付加的な接着剤記録を代理人に挿入する問題を持ってください。 これらの接着剤の1つが間違っているなら、他のネームサーバに誤りを伝播できます。 2つのネームサーバが互いの他のゾーンへの代理人であるなら、1つが絶えず古い接着剤記録をもう片方に戻すのは、可能です。 排除するようになる唯一の方法

Barr                         Informational                      [Page 5]

RFC 1912                   Common DNS Errors               February 1996

一般的な[5ページ]RFC1912DNS誤り1996年2月の情報のバール

   the old data is to kill both of them, remove the saved backup files,
   and restart them.  Combined with that those same versions also tend
   to become infected more easily with bogus data found in other non-
   secondary nameservers (like the root zone data).

古いデータは、それらの両方を殺して、保存しているバックアップファイルを取り除いて、それらを再開することです。 それに結合されて、また、それらの同じバージョンは、にせのデータが他の非セカンダリのネームサーバ(ルートゾーンデータのような)で見つけられている状態で、より容易に感染するようになる傾向があります。

2.4 CNAME records

2.4 CNAME記録

   A CNAME record is not allowed to coexist with any other data.  In
   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
   can't also have an MX record for suzy.podunk.edu, or an A record, or
   even a TXT record.  Especially do not try to combine CNAMEs and NS
   records like this!:

CNAME記録はいかなる他のデータとも共存できません。 言い換えれば、また、suzy.podunk.xxがsue.podunk.xxのための別名であるなら、あなたはMXにsuzy.podunk.edu、A記録、またはTXT記録のためにさえ記録させることができません。 このようなCNAMEsとNS記録を特に結合しようとしないでください、!:

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
                           IN      CNAME   mary
           mary            IN      A       1.2.3.4

podunk.xx。 IN NS ns1IN NS ns2IN CNAME mary mary IN A1.2.3.4

   This is often attempted by inexperienced administrators as an obvious
   way to allow your domain name to also be a host.  However, DNS
   servers like BIND will see the CNAME and refuse to add any other
   resources for that name.  Since no other records are allowed to
   coexist with a CNAME, the NS entries are ignored.  Therefore all the
   hosts in the podunk.xx domain are ignored as well!

これはまた、あなたのドメイン名がホストであることを許容する当たり前の方法としてしばしば未経験な管理者によって試みられます。 しかしながら、BINDのようなDNSサーバは、CNAMEを見て、その名前のためのいかなる他のリソースも加えるのを拒否するでしょう。 他のどんな記録もCNAMEと共存できないので、NSエントリーは無視されます。 したがって、また、podunk.xxドメインのすべてのホストが無視されます!

   If you want to have your domain also be a host, do the following:

また、あなたのドメインがホストであることを持ちたいなら、以下をしてください:

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
                           IN      A       1.2.3.4
           mary            IN      A       1.2.3.4

podunk.xx。 IN NS ns1IN NS ns2IN A1.2.3.4mary IN A1.2.3.4

   Don't go overboard with CNAMEs.  Use them when renaming hosts, but
   plan to get rid of them (and inform your users).  However CNAMEs are
   useful (and encouraged) for generalized names for servers -- `ftp'
   for your ftp server, `www' for your Web server, `gopher' for your
   Gopher server, `news' for your Usenet news server, etc.

CNAMEsと共に船から落ちないでください。 ホストを改名するときにはそれらを使用しなさい、ただし、彼らを取り除くのを計画してください(ユーザに知らせてください)。 しかしながら、CNAMEsはサーバで一般化された名前の役に立ちます(そして、奨励されます)--あなたのftpサーバのための'ftp'、あなたのウェブサーバのための'www'、あなたのゴーファーサーバのための'リス'、あなたのUsenetニュースサーバのための'ニュース'など

   Don't forget to delete the CNAMEs associated with a host if you
   delete the host it is an alias for.  Such "stale CNAMEs" are a waste
   of resources.

それがあなたがホストを削除するならホストに関連づけられたCNAMEsを削除するためには、別名であったのを忘れないでください。 そのような「聞き古したCNAMEs」はリソースの浪費です。

Barr                         Informational                      [Page 6]

RFC 1912                   Common DNS Errors               February 1996

一般的な[6ページ]RFC1912DNS誤り1996年2月の情報のバール

   Don't use CNAMEs in combination with RRs which point to other names
   like MX, CNAME, PTR and NS.  (PTR is an exception if you want to
   implement classless in-addr delegation.)  For example, this is
   strongly discouraged:

Mx、CNAME、PTR、およびNSのような他の名前を示すRRsと組み合わせてCNAMEsを使用しないでください。 (あなたがaddrの階級のない委譲を実装したいなら、PTRは例外です。) 例えば、これは強くがっかりしています:

           podunk.xx.      IN      MX      mailhost
           mailhost        IN      CNAME   mary
           mary            IN      A       1.2.3.4

podunk.xx。 IN MX mailhost mailhost IN CNAME mary mary IN A1.2.3.4

   [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
   974] explicitly states that MX records shall not point to an alias
   defined by a CNAME.  This results in unnecessary indirection in
   accessing the data, and DNS resolvers and servers need to work more
   to get the answer.  If you really want to do this, you can accomplish
   the same thing by using a preprocessor such as m4 on your host files.

セクション3.6.2における[RFC1034]は、これが完了しているべきでないと言います、そして、[RFC974]はMX記録がCNAMEによって定義された別名を示さないだろうと明らかに述べます。 これはデータにアクセスする際に不要な間接指定をもたらします、そして、DNSレゾルバとサーバは答えを得るためにさらに働く必要があります。 あなたが本当にこれをしたいなら、あなたは、あなたのホストファイルの上のm4などのプリプロセッサを使用することによって、同じものを達成できます。

   Also, having chained records such as CNAMEs pointing to CNAMEs may
   make administration issues easier, but is known to tickle bugs in
   some resolvers that fail to check loops correctly.  As a result some
   hosts may not be able to resolve such names.

また、CNAMEsを示すCNAMEsなどの記録をチェーニングしたのは、管理問題をより簡単にするかもしれませんが、正しく輪をチェックしない何人かのレゾルバでバグをくすぐるのが知られています。 その結果、何人かのホストはそのような名前を決議できないかもしれません。

   Having NS records pointing to a CNAME is bad and may conflict badly
   with current BIND servers.  In fact, current BIND implementations
   will ignore such records, possibly leading to a lame delegation.
   There is a certain amount of security checking done in BIND to
   prevent spoofing DNS NS records.  Also, older BIND servers reportedly
   will get caught in an infinite query loop trying to figure out the
   address for the aliased nameserver, causing a continuous stream of
   DNS requests to be sent.

CNAMEを示すNS記録を持っているのは、悪く、ひどく現在のBINDサーバと衝突するかもしれません。 事実上、ことによると不十分な委譲に通じて、現在のBIND実装はそのような記録を無視するでしょう。 DNS NSが記録であると偽造するのを防ぐためにBINDで行われたある量のセキュリティー検査があります。 また、伝えられるところによれば、より古いBINDサーバはaliasedネームサーバのためのアドレスを理解しようとしながら、無限の質問輪に捕らえられるでしょう、送られるというDNS要求の連続したストリームを引き起こして。

2.5 MX records

2.5 MX記録

   It is a good idea to give every host an MX record, even if it points
   to itself!  Some mailers will cache MX records, but will always need
   to check for an MX before sending mail.  If a site does not have an
   MX, then every piece of mail may result in one more resolver query,
   since the answer to the MX query often also contains the IP addresses
   of the MX hosts.  Internet SMTP mailers are required by [RFC 1123] to
   support the MX mechanism.

それ自体を示しても、MX記録をすべてのホストに与えるのは、名案です! 何人かの郵送者が、MX記録をキャッシュしますが、いつもメールを送る前にMXがないかどうかチェックする必要があるでしょう。 サイトにMXがないなら、あらゆる郵便配達人はもうひとつのレゾルバ質問をもたらすかもしれません、また、MX質問の答えがしばしばMXホストのIPアドレスを含んでいるので。 インターネットSMTP郵送者は[RFC1123]はMXメカニズムをサポートしなければなりません。

   Put MX records even on hosts that aren't intended to send or receive
   e-mail.  If there is a security problem involving one of these hosts,
   some people will mistakenly send mail to postmaster or root at the
   site without checking first to see if it is a "real" host or just a
   terminal or personal computer that's not set up to accept e-mail.  If
   you give it an MX record, then the e-mail can be redirected to a real
   person.  Otherwise mail can just sit in a queue for hours or days

メールを送るか、または受け取ることを意図しないホストにさえ、MX記録を置いてください。 これらのホストのひとりを伴うことにおける警備上の問題があると、最初に、それがただメールを受け入れるためにセットアップされていない「本当」のホスト、端末またはパーソナルコンピュータであるかを確認するためにチェックしないで、何人かの人々が、メールを郵便局長に誤って送るか、またはサイトに根づくでしょう。 あなたがMX記録をそれに与えるなら、メールを実在の人物に転送できます。 さもなければ、何時間も何日もメールは待ち行列でただ座ることができます。

Barr                         Informational                      [Page 7]

RFC 1912                   Common DNS Errors               February 1996

一般的な[7ページ]RFC1912DNS誤り1996年2月の情報のバール

   until the mailer gives up trying to send it.

郵送者が、それを送ろうとするのをやめるまで。

   Don't forget that whenever you add an MX record, you need to inform
   the target mailer if it is to treat the first host as "local".  (The
   "Cw" flag in sendmail, for example)

あなたがMX記録を加えるときはいつも、それが「地方」として第1代ホストを扱うつもりであるかどうかを目標郵送者に知らせるのが必要であることを忘れないでください。 (例えば、sendmailの"Cw"旗)

   If you add an MX record which points to an external host (e.g., for
   the purposes of backup mail routing) be sure to ask permission from
   that site first.  Otherwise that site could get rather upset and take
   action (like throw your mail away, or appeal to higher authorities
   like your parent DNS administrator or network provider.)

外部のホスト(例えば、バックアップメールルーティングの目的のための)を示すMX記録を加えるなら、最初に、そのサイトから許可を必ず尋ねてください。 さもなければ、そのサイトは、むしろ動揺していて、行動を取るかもしれません。(同類は、あなたの親DNS管理者やネットワーク内の提供者のようにあなたのメールを無駄にするか、または、より高い当局の好みに合います。)

2.6 Other Resource Records

2.6 他のリソース記録

2.6.1 WKS

2.6.1 WKS

   WKS records are deprecated in [RFC 1123].  They serve no known useful
   function, except internally among LISP machines.  Don't use them.

WKS記録は[RFC1123]で推奨しないです。 彼らはどんな知られている役に立つ機能も果たさないで、LISPマシンの中で内部的に除いてください。 それらを使用しないでください。

2.6.2 HINFO

2.6.2 HINFO

   On the issue HINFO records, some will argue that these is a security
   problem (by broadcasting what vendor hardware and operating system
   you so people can run systematic attacks on known vendor security
   holes).  If you do use them, you should keep up to date with known
   vendor security problems.  However, they serve a useful purpose.
   Don't forget that HINFO requires two arguments, the hardware type,
   and the operating system.

問題HINFO記録では、或るものは、これらが警備上の問題であると主張するでしょう(どんなベンダーハードウェアとオペレーティングシステムを放送するかによって、人々が系統的に走ることができるように、あなたは知られているベンダーセキュリティーホールで攻撃します)。 それらを使用するなら、あなたは知られているベンダーセキュリティで問題が時代について行かせるべきです。しかしながら、それらは目的に有効に適います。 HINFOが2つの議論、ハードウェアタイプ、およびオペレーティングシステムを必要とするのを忘れないでください。

   HINFO is sometimes abused to provide other information.  The record
   is meant to provide specific information about the machine itself.
   If you need to express other information about the host in the DNS,
   use TXT.

HINFOは、他の情報を提供するために時々誤用されます。 記録はマシン自体に関する特殊情報を提供することになっています。 DNSでホストの他の情報を言い表す必要があるなら、TXTを使用してください。

2.6.3 TXT

2.6.3 TXT

   TXT records have no specific definition.  You can put most anything
   in them.  Some use it for a generic description of the host, some put
   specific information like its location, primary user, or maybe even a
   phone number.

TXT記録には、どんな特定の定義もありません。 あなたはほとんどの何でも彼らに入れることができます。 或るものはホストのジェネリック記述にそれを使用して、或るものは位置、主たる利用者、または多分電話番号のようにさえ特殊情報を置きます。

2.6.4 RP

2.6.4 RP

   RP records are relatively new.  They are used to specify an e-mail
   address (see first paragraph of section 2.2)  of the "Responsible
   Person" of the host, and the name of a TXT record where you can get
   more information.  See [RFC 1183].

RP記録は比較的新しいです。 それらは、ホストの「責任者」のEメールアドレス(セクション2.2の第一節を見る)、およびあなたが詳しい情報を得ることができるTXT記録の名前を指定するのに使用されます。 [RFC1183]を見てください。

Barr                         Informational                      [Page 8]

RFC 1912                   Common DNS Errors               February 1996

一般的な[8ページ]RFC1912DNS誤り1996年2月の情報のバール

2.7 Wildcard records

2.7 ワイルドカード記録

   Wildcard MXs are useful mostly for non IP-connected sites.  A common
   mistake is thinking that a wildcard MX for a zone will apply to all
   hosts in the zone.  A wildcard MX will apply only to names in the
   zone which aren't listed in the DNS at all.  e.g.,

ワイルドカードMXsはほとんど非IPが接続しているサイトの役に立ちます。 一般的な誤りは、ゾーンへのMXがそうするワイルドカードがゾーンのすべてのホストに適用されると思っています。 MXがゾーンの全くDNSに記載されていない名前だけに適用するワイルドカード、例えば。

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
           mary            IN      A       1.2.3.4
           *.podunk.xx.    IN      MX      5 sue

podunk.xx。 IN NS ns1IN NS ns2 mary IN A1.2.3.4*.podunk.xx。 IN MX5は訴えます。

   Mail for mary.podunk.xx will be sent to itself for delivery.  Only
   mail for jane.podunk.xx or any hosts you don't see above will be sent
   to the MX.  For most Internet sites, wildcard MX records are not
   useful.  You need to put explicit MX records on every host.

配送のためにmary.podunk.xxのためのメールをそれ自体に送るでしょう。 jane.podunk.xxのためのメールかあなたが上であることを見ないどんなホストだけもMXに送るでしょう。 ほとんどのインターネット・サイトには、ワイルドカードMX記録が役に立ちません。 あなたは、明白なMX記録をすべてのホストに置く必要があります。

   Wildcard MXs can be bad, because they make some operations succeed
   when they should fail instead.  Consider the case where someone in
   the domain "widget.com" tries to send mail to "joe@larry".  If the
   host "larry" doesn't actually exist, the mail should in fact bounce
   immediately.  But because of domain searching the address gets
   resolved to "larry.widget.com", and because of the wildcard MX this
   is a valid address according to DNS.  Or perhaps someone simply made
   a typo in the hostname portion of the address.  The mail message then
   gets routed to the mail host, which then rejects the mail with
   strange error messages like "I refuse to talk to myself" or "Local
   configuration error".

代わりに失敗すると彼らがいくつかの操作を成功させるので、ワイルドカードMXsは悪い場合があります。 ドメイン"widget.com"のだれかが" joe@larry "にメールを送ろうとするケースを考えてください。 ホスト"larry"が実際に存在していないなら、事実上、メールはすぐに、戻って来るべきです。 しかし、ドメインの探すので、アドレスは"larry.widget.com"に決議されています、そして、ワイルドカードMXのために、DNSによると、これは有効なアドレスです。 または、恐らく、だれかがアドレスのホスト名部分で単に誤植を作りました。 そして、メール・メッセージはメールホストに発送されます。(次に、そのホストは、「私は、自分と話すのを拒否する」か、「地方の構成誤り」のような奇妙なエラーメッセージでメールを拒絶します)。

   Wildcard MX records are good for when you have a large number of
   hosts which are not directly Internet-connected (for example, behind
   a firewall) and for administrative or political reasons it is too
   difficult to have individual MX records for every host, or to force
   all e-mail addresses to be "hidden" behind one or more domain names.
   In that case, you must divide your DNS into two parts, an internal
   DNS, and an external DNS.  The external DNS will have only a few
   hosts and explicit MX records, and one or more wildcard MXs for each
   internal domain.  Internally the DNS will be complete, with all
   explicit MX records and no wildcards.

ワイルドカードMX記録はあなたがホストのインターネットで直接関連していない(例えばファイアウォールの後ろで)多くを持っている時とすべてのホストへの個々のMX記録を持っているか、またはすべてのEメールアドレスが1つ以上のドメイン名の後ろに「隠されること」を強制するのが難し過ぎる管理の、または、政治上の理由で良いです。 その場合、あなたはDNSを2つの部品、内部のDNS、および外部のDNSに分割しなければなりません。 外部のDNSはほんのいくつかのホストと明白なMX記録、および1個以上のワイルドカードMXsをそれぞれの内部のドメインに持つでしょう。 本質的に、DNSはすべての明白なMX記録にもかかわらず、どんなワイルドカードでも完全にならないでしょう。

   Wildcard As and CNAMEs are possible too, and are really confusing to
   users, and a potential nightmare if used without thinking first.  It
   could result (due again to domain searching) in any telnet/ftp
   attempts from within the domain to unknown hosts to be directed to
   one address.  One such wildcard CNAME (in *.edu.com) caused
   Internet-wide loss of services and potential security nightmares due
   to unexpected interactions with domain searching.  It resulted in
   swift fixes, and even an RFC ([RFC 1535]) documenting the problem.

最初に思わないで、ワイルドカードAsとCNAMEsはまた、可能であり、本当にユーザ、および潜在的悪夢に紛らわしいのですが、使用されています。 それは、1つのアドレスに向けられるためにどんなドメインから未知のホストまでのtelnet/ftp試みようにも結果として生じることができました(再びドメインの探すのに当然の)。 1そのようなワイルドカードCNAME(*.edu.comの)がドメインの探すとの予期していなかった相互作用によるインターネット全体のサービスの損失と潜在的セキュリティ悪夢を引き起こしました。 それは迅速なフィックス、および問題を記録するRFC([RFC1535])さえもたらしました。

Barr                         Informational                      [Page 9]

RFC 1912                   Common DNS Errors               February 1996

一般的な[9ページ]RFC1912DNS誤り1996年2月の情報のバール

2.8 Authority and Delegation Errors (NS records)

2.8 権威と委譲誤り(NS記録)

   You are required to have at least two nameservers for every domain,
   though more is preferred.  Have secondaries outside your network.  If
   the secondary isn't under your control, periodically check up on them
   and make sure they're getting current zone data from you.  Queries to
   their nameserver about your hosts should always result in an
   "authoritative" response.  If not, this is called a "lame
   delegation".  A lame delegations exists when a nameserver is
   delegated responsibility for providing nameservice for a zone (via NS
   records) but is not performing nameservice for that zone (usually
   because it is not set up as a primary or secondary for the zone).

あなたには、以上は好まれますが、各ドメインあたり少なくとも2つのネームサーバがなければなりません。 代理人はネットワークの外にいてください。 セカンダリがあなたのコントロールの下にないなら、定期的にそれらを調べてください、そして、彼らが現在のゾーンデータを得ているのを確実にしてください。 あなたのホストに関するそれらのネームサーバへの質問はいつも「正式」の応答をもたらすべきです。 そうでなければ、これは「不十分な委譲」と呼ばれます。 不十分な委譲は、ネームサーバがゾーン(NS記録を通した)にnameserviceを提供することへの代表として派遣された責任であるときに、存在していますが、そのゾーンにnameserviceを実行していません(通常、それが予備選挙として上がっているかゾーンにおける、セカンダリのセットでないので)。

   The "classic" lame delegation can be illustrated in this example:

この例で不十分な「古典的な」委譲を例証できます:

           podunk.xx.      IN      NS      ns1.podunk.xx.
                           IN      NS      ns0.widget.com.

podunk.xx。 IN NS ns1.podunk.xx。 IN NS ns0.widget.com。

   "podunk.xx" is a new domain which has recently been created, and
   "ns1.podunk.xx" has been set up to perform nameservice for the zone.
   They haven't quite finished everything yet and haven't made sure that
   the hostmaster at "ns0.widget.com" has set up to be a proper
   secondary, and thus has no information about the podunk.xx domain,
   even though the DNS says it is supposed to.  Various things can
   happen depending on which nameserver is used.  At best, extra DNS
   traffic will result from a lame delegation.  At worst, you can get
   unresolved hosts and bounced e-mail.

"podunk.xx"は最近作成された新しいドメインです、そして、"ns1.podunk.xx"は、ゾーンにnameserviceを実行するためにセットアップされました。 "ns0.widget.com"のhostmasterがセットを適切な2番目になるように上がるようにして、その結果、podunk.xxドメインの情報を全く持っていないのを確信しているのに作られていて、彼らは全くまだすべてを終えるというわけではなくて、持たないでください、DNSは、それが思われると言いますが。 どのネームサーバが使用されているかによって、様々なことは起こることができます。 せいぜい、付加的なDNSトラフィックは不十分な委譲から生じるでしょう。 最悪の場合は、あなたは未定のホストと弾んでいるメールを得ることができます。

   Also, sometimes a nameserver is moved to another host or removed from
   the list of secondaries.  Unfortunately due to caching of NS records,
   many sites will still think that a host is a secondary after that
   host has stopped providing nameservice.  In order to prevent lame
   delegations while the cache is being aged, continue to provide
   nameservice on the old nameserver for the length of the maximum of
   the minimum plus refresh times for the zone and the parent zone.
   (See section 2.2)

また、ネームサーバは、時々、別のホストに動かされるか、または代理人のリストから移されます。 残念ながら、それでも、NS記録のキャッシュのため、多くのサイトが、そのホストが、nameserviceを提供するのを止めた後にホストが2番目であると思うでしょう。 キャッシュが熟成している間、不十分な委譲を防ぐには、古いネームサーバで最小限の最大の長さにnameserviceを提供して、ゾーンと親ゾーンに回をリフレッシュし続けてください。 (セクション2.2を見ます)

   Whenever a primary or secondary is removed or changed, it takes a
   fair amount of human coordination among the parties involved.  (The
   site itself, it's parent, and the site hosting the secondary)  When a
   primary moves, make sure all secondaries have their named.boot files
   updated and their servers reloaded.  When a secondary moves, make
   sure the address records at both the primary and parent level are
   changed.

予備選挙か2番目を外すか、または変えるときはいつも、それは公正な量の人間のコーディネートをかかわったパーティーに取ります。 (サイト自体であり、それは、親と、セカンダリを接待するサイトです) 予備選挙が移行するときには、すべての代理人が彼らのnamed.boot filesをアップデートさせて、彼らのサーバに再び荷を積んだのを確実にしてください。 セカンダリ移動であることの、ときには、予備選挙と親レベルの両方でのアドレス記録が変えられるのを確実にしてください。

   It's also been reported that some distant sites like to pick popular
   nameservers like "ns.uu.net" and just add it to their list of NS
   records in hopes that they will magically perform additional

また、"ns.uu.net"のようなポピュラーなネームサーバを選んで、魔法にかかったように望んでいるという望みでそれらのNS記録のリストにそれをただ追加するために同様のいくつかの遠位部位が働くと報告された、追加

Barr                         Informational                     [Page 10]

RFC 1912                   Common DNS Errors               February 1996

一般的な[10ページ]RFC1912DNS誤り1996年2月の情報のバール

   nameservice for them.  This is an even worse form of lame delegation,
   since this adds traffic to an already busy nameserver.  Please
   contact the hostmasters of sites which have lame delegations.
   Various tools can be used to detect or actively find lame
   delegations.  See the list of contributed software in the BIND
   distribution.

それらのためのnameservice。 これはさらに悪い作法の不十分な委譲です、これが既に忙しいネームサーバにトラフィックを加えるので。不十分な委譲を持っているサイトのhostmastersに連絡してください。 不十分な委譲を検出するか、または活発に見つけるのに様々なツールを使用できます。 BIND分配で寄付されたソフトウェアのリストを見てください。

   Make sure your parent domain has the same NS records for your zone as
   you do.  (Don't forget your in-addr.arpa zones too!).  Do not list
   too many (7 is the recommended maximum), as this just makes things
   harder to manage and is only really necessary for very popular top-
   level or root zones.  You also run the risk of overflowing the 512-
   byte limit of a UDP packet in the response to an NS query.  If this
   happens, resolvers will "fall back" to using TCP requests, resulting
   in increased load on your nameserver.

親ドメインがあなたとしてのあなたのゾーンのための記録がする同じNSを持っているのを確実にしてください。 (addr.arpaのゾーンも忘れないでください!) また、多くを記載しないでください(7はお勧めの最大です)、これが事態を管理するのをより困難にただして、本当にだけ非常にポピュラーな最高レベルかルートゾーンに必要であるので。 また、あなたはNS質問への応答で512バイトが制限するUDPパケットのオーバフローの危険を冒します。 これが起こると、レゾルバはあなたのネームサーバで増強された負荷をもたらして、TCP要求を使用することへ「後ろへ下がるでしょう」。

   It's important when picking geographic locations for secondary
   nameservers to minimize latency as well as increase reliability.
   Keep in mind network topologies.  For example if your site is on the
   other end of a slow local or international link, consider a secondary
   on the other side of the link to decrease average latency.  Contact
   your Internet service provider or parent domain contact for more
   information about secondaries which may be available to you.

セカンダリネームサーバが潜在を最小にして、信頼性を増強するように地理的な位置を選ぶとき、それは重要です。 ネットワークtopologiesを覚えておいてください。 例えば、サイトが遅い地方的、または、国際的なリンクのもう一方の端にあるなら、リンクの反対側の上の2番目が平均した潜在を減少させると考えてください。 代理人に関するあなたにとって、利用可能であるかもしれない詳しい情報のためにインターネット接続サービス業者か親ドメイン接触に連絡してください。

3. BIND operation

3. BIND操作

   This section discusses common problems people have in the actual
   operation of the nameserver (specifically, BIND).  Not only must the
   data be correct as explained above, but the nameserver must be
   operated correctly for the data to be made available.

このセクションは人々がネームサーバ(明確にBIND)の実際の運営で持っている共有する問題について論じます。 データが単に上で説明されるように正しいに違いないのではなく、データを利用可能にするように正しくネームサーバを操作しなければなりません。

3.1 Serial numbers

3.1 通し番号

   Each zone has a serial number associated with it.  Its use is for
   keeping track of who has the most current data.  If and only if the
   primary's serial number of the zone is greater will the secondary ask
   the primary for a copy of the new zone data (see special case below).

各ゾーンには、それに関連している通し番号があります。 使用は、だれに最も現在のデータがあるかに関する道を保つものです。 予備選挙のゾーンの通し番号である場合にだけ、2番目がコピーするようにaのための予備選挙に頼む新しいゾーンデータ(特別なケース下を見る)の、よりすごい意志はそうです。

   Don't forget to change the serial number when you change data!  If
   you don't, your secondaries will not transfer the new zone
   information.  Automating the incrementing of the serial number with
   software is also a good idea.

データを変えるとき、通し番号を変えるのを忘れないでください! あなたがそうしないと、あなたの代理人は新しいゾーン情報を移さないでしょう。 また、ソフトウェアによる通し番号の増加を自動化するのは、名案です。

   If you make a mistake and increment the serial number too high, and
   you want to reset the serial number to a lower value, use the
   following procedure:

誤りと増分を通し番号にあまり高くして、下側の値に通し番号をリセットしたいなら、以下の手順を用いてください:

Barr                         Informational                     [Page 11]

RFC 1912                   Common DNS Errors               February 1996

一般的な[11ページ]RFC1912DNS誤り1996年2月の情報のバール

      Take the `incorrect' serial number and add 2147483647 to it.  If
      the number exceeds 4294967296, subtract 4294967296.  Load the
      resulting number.  Then wait 2 refresh periods to allow the zone
      to propagate to all servers.

'不正確な'通し番号を取ってください、そして、それに2147483647を加えてください。 数が4294967296を超えているなら、4294967296を引き算してください。 結果として起こる数をロードしてください。 そして、待2ちはゾーンがすべてのサーバに伝播するのを許容する期間をリフレッシュします。

      Repeat above until the resulting serial number is less than the
      target serial number.

上で結果として起こる通し番号が目標通し番号以下になるまで繰り返してください。

      Up the serial number to the target serial number.

目標通し番号への通し番号に。

   This procedure won't work if one of your secondaries is running an
   old version of BIND (4.8.3 or earlier).  In this case you'll have to
   contact the hostmaster for that secondary and have them kill the
   secondary servers, remove the saved backup file, and restart the
   server.  Be careful when editing the serial number -- DNS admins
   don't like to kill and restart nameservers because you lose all that
   cached data.

または、あなたの代理人のひとりが扱うとこの手順がBINDの古いバージョンを実行しながら扱わない、(4.8、.3、 より早い) この場合、あなたは、それにおける、セカンダリのhostmasterに連絡して、彼らがセカンダリサーバを殺して、保存しているバックアップファイルを取り除いて、サーバを再開するのを持たなければならないでしょう。通し番号を編集するときには、注意してください--あなたがデータをキャッシュしたすべてを失うので、DNSアドミンは、殺すのが好きであり、ネームサーバを再開しません。

3.2 Zone file style guide

3.2 ゾーンファイルスタイルガイド

   Here are some useful tips in structuring your zone files.  Following
   these will help you spot mistakes, and avoid making more.

ここに、あなたのゾーンファイルを構造化することにおけるいくつかの役に立つヒントがあります。 これらに続くのは、あなたが誤りを見つけるのを助けて、さらに作るのを避けるでしょう。

   Be consistent with the style of entries in your DNS files. If your
   $ORIGIN is podunk.xx., try not to write entries like:

DNSファイルにおける、エントリーのスタイルと一致してください。 あなたの$ORIGINがpodunk.xxであるなら書く、以下のようにエントリーを書こうとしないでください。

           mary            IN      A       1.2.3.1
           sue.podunk.xx.  IN      A       1.2.3.2

mary IN A1.2.3.1sue.podunk.xx。 IN A1.2.3、.2

   or:

または、:

           bobbi           IN      A       1.2.3.2
                           IN      MX      mary.podunk.xx.

bobbi IN A1.2.3.2IN MX mary.podunk.xx。

   Either use all FQDNs (Fully Qualified Domain Names) everywhere or
   used unqualified names everywhere.  Or have FQDNs all on the right-
   hand side but unqualified names on the left.  Above all, be
   consistent.

どちらかがすべてのFQDNsを使用する、(完全である、Qualified Domain Names)、いたる所、または、いたる所の中古の資格のない名前。 または、すべて左の正しい手の側にもかかわらず、資格のない名前にFQDNsを持ってください。 何よりも、一貫してください。

   Use tabs between fields, and try to keep columns lined up.  It makes
   it easier to spot missing fields (note some fields such as "IN" are
   inherited from the previous record and may be left out in certain
   circumstances.)

分野の間のタブを使用してください、そして、コラムを並べ続けるようにしてください。 それで、なくなった分野を見つけるのは、より簡単になります。(「IN」などのいくつかの分野が前の記録から引き継がれて、ある特定の状況では省かれるかもしれないことに注意してください。)

Barr                         Informational                     [Page 12]

RFC 1912                   Common DNS Errors               February 1996

一般的な[12ページ]RFC1912DNS誤り1996年2月の情報のバール

   Remember you don't need to repeat the name of the host when you are
   defining multiple records for one host.  Be sure also to keep all
   records associated with a host together in the file.  It will make
   things more straightforward when it comes time to remove or rename a
   host.

1人のホストのために複数の記録を定義しているとき、ホストの名前を繰り返す必要はないのを覚えていてください。 また、ファイルにホストに関連しているすべての記録を必ずまとめてください。 それはホストを免職するか、または改名する時間を来ると、より簡単なものにするでしょう。

   Always remember your $ORIGIN.  If you don't put a `.' at the end of
   an FQDN, it's not recognized as an FQDN.  If it is not an FQDN, then
   the nameserver will append $ORIGIN to the name.  Double check, triple
   check, those trailing dots, especially in in-addr.arpa zone files,
   where they are needed the most.

いつも$ORIGINを覚えていてください。 'あなたがaを置かないなら'。'FQDNの端では、それはFQDNとして認識されません。 それがFQDNでないなら、ネームサーバは$ORIGINを名前に追加するでしょう。 ものがドットを引きずって、特にaddr.arpaのゾーンファイルで二重に、チェックしてください、そして、3倍チェックしてください。そこでは、それらが最も必要です。

   Be careful with the syntax of the SOA and WKS records (the records
   which use parentheses).  BIND is not very flexible in how it parses
   these records.  See the documentation for BIND.

SOAとWKS記録(括弧を使用する記録)の構文に注意してください。 それがどうこれらの記録を分析するかでBINDはそれほどフレキシブルではありません。 BINDに関してドキュメンテーションを見てください。

3.3 Verifying data

3.3 データについて確かめること。

   Verify the data you just entered or changed by querying the resolver
   with dig (or your favorite DNS tool, many are included in the BIND
   distribution) after a change.  A few seconds spent double checking
   can save hours of trouble, lost mail, and general headaches.  Also be
   sure to check syslog output when you reload the nameserver.  If you
   have grievous errors in your DNS data or boot file, named will report
   it via syslog.

あなたが変化の後に皮肉(あなたのお気に入りのDNSツールであり、多くがBIND分配に含まれている)でレゾルバについて質問することによってただ入力したか、または変えたデータについて確かめてください。 数秒、費やされた二重照合は何時間もの手間、無くなっているメール、および一般的な頭痛を省くことができます。 また、ネームサーバを再び積むときにはsyslog出力を必ずチェックしてください。あなたのDNSデータかブート・ファイルにおける悲しい誤りがありましたら、命名されて、syslogを通してそれを報告するでしょう。

   It is also highly recommended that you automate this checking, either
   with software which runs sanity checks on the data files before they
   are loaded into the nameserver, or with software which checks the
   data already loaded in the nameserver.  Some contributed software to
   do this is included in the BIND distribution.

また、あなたがそれらがネームサーバに積み込まれる前に健全度チェックをデータファイルに実行するソフトウェア、またはネームサーバで既にロードされたデータをチェックするソフトウェアでこの照合を自動化するのも、非常にお勧めです。これをする何らかの寄付されたソフトウェアがBIND分配に含まれています。

4. Miscellaneous Topics

4. 種々雑多な話題

4.1 Boot file setup

4.1 ブート・ファイルセットアップ

   Certain zones should always be present in nameserver configurations:

ある一定のゾーンはネームサーバ構成でいつも存在しているべきです:

           primary         localhost               localhost
           primary         0.0.127.in-addr.arpa    127.0
           primary         255.in-addr.arpa        255
           primary         0.in-addr.arpa          0

プライマリプライマリlocalhost localhostのプライマリ255.in-addr.arpa255プライマリ0.0.127.in-addr.arpa127.0 0.in-addr.arpa0

   These are set up to either provide nameservice for "special"
   addresses, or to help eliminate accidental queries for broadcast or
   local address to be sent off to the root nameservers.  All of these
   files will contain NS and SOA records just like the other zone files
   you maintain, the exception being that you can probably make the SOA

これらは、「特別な」アドレスにnameserviceを前提とするか、または放送かローカルアドレスを根のネームサーバに送るために偶然の質問を排除するのを助けるためにセットアップされます。 これらのファイルのすべてがまさしくあなたが保守する他のゾーンファイルのようなNSとSOA記録を含むでしょう、例外があなたがたぶんSOAを作ることができるということであり

Barr                         Informational                     [Page 13]

RFC 1912                   Common DNS Errors               February 1996

一般的な[13ページ]RFC1912DNS誤り1996年2月の情報のバール

   timers very long, since this data will never change.

タイマ、このデータが決して変えないので、非常に長くて、変化してください。

   The "localhost" address is a "special" address which always refers to
   the local host.  It should contain the following line:

"localhost"アドレスはいつもローカル・ホストについて言及する「特別な」アドレスです。 それは以下の系列を含むべきです:

           localhost.      IN      A       127.0.0.1

localhost。 IN A127.0.0、.1

   The "127.0" file should contain the line:

「127.0」ファイルは系列を含むはずです:

           1    PTR     localhost.

1 PTR localhost。

   There has been some extensive discussion about whether or not to
   append the local domain to it.  The conclusion is that "localhost."
   would be the best solution.  The reasons given include:

局所領域をそれに追加するかどうか何らかの大規模な議論がありました。 結論はその"localhost"です。最も良いソリューションでしょう。 あげられた理由は:

      "localhost" by itself is used and expected to work in some
      systems.

それ自体で"localhost"は、使用されて、いくつかのシステムで働くと予想されます。

      Translating 127.0.0.1 into "localhost.dom.ain" can cause some
      software to connect back to the loopback interface when it didn't
      want to because "localhost" is not equal to "localhost.dom.ain".

翻訳、127.0、.0、.1、"localhost"が"localhost.dom.ain"と等しくないので引き起こしたがっていなかったとき、"localhost.dom.ain"に、何らかのソフトウェアがループバックインタフェースに接続して戻ることを引き起こす場合があります。

   The "255" and "0" files should not contain any additional data beyond
   the NS and SOA records.

「255」 そして、「0インチのファイルはナノ秒とSOA記録を超えて少しの追加データも含むはずがありません」。

   Note that future BIND versions may include all or some of this data
   automatically without additional configuration.

将来のBINDバージョンが追加構成なしでこのすべてかいくつかのデータを自動的に含むかもしれないことに注意してください。

4.2 Other Resolver and Server bugs

4.2 他のResolverとServerバグ

   Very old versions of the DNS resolver have a bug that cause queries
   for names that look like IP addresses to go out, because the user
   supplied an IP address and the software didn't realize that it didn't
   need to be resolved.  This has been fixed but occasionally it still
   pops up.  It's important because this bug means that these queries
   will be sent directly to the root nameservers, adding to an already
   heavy DNS load.

DNSレゾルバの非常に古いバージョンは原因が出かけるIPアドレスに似ている名前のために質問するバグを持っています、ユーザがIPアドレスを供給して、ソフトウェアが、決議される必要はないとわからなかったので。 これは修理されましたが、時折、それはまだ急に現れています。 このバグが、これらの質問が直接根のネームサーバに送られることを意味するので、それは重要です、既に重いDNS荷重の一助となって。

   While running a secondary nameserver off another secondary nameserver
   is possible, it is not recommended unless necessary due to network
   topologies.  There are known cases where it has led to problems like
   bogus TTL values.  While this may be caused by older or flawed DNS
   implementations, you should not chain secondaries off of one another
   since this builds up additional reliability dependencies as well as
   adds additional delays in updates of new zone data.

別のセカンダリネームサーバにセカンダリネームサーバを流出するのが可能である間、ネットワークtopologiesのために必要でない場合、それは推薦されません。 それがにせのTTL値のような問題を引き起こしたケースは知られています。 これが、より古いか失敗するDNS実装によって引き起こされているかもしれない間、これが追加信頼性の依存を確立して、新しいゾーンデータのアップデートの追加遅れを加えるので、あなたはお互いから代理人を鎖でつなぐべきではありません。

Barr                         Informational                     [Page 14]

RFC 1912                   Common DNS Errors               February 1996

一般的な[14ページ]RFC1912DNS誤り1996年2月の情報のバール

4.3 Server issues

4.3 サーバ問題

   DNS operates primarily via UDP (User Datagram Protocol) messages.
   Some UNIX operating systems, in an effort to save CPU cycles, run
   with UDP checksums turned off.  The relative merits of this have long
   been debated.  However, with the increase in CPU speeds, the
   performance considerations become less and less important.  It is
   strongly encouraged that you turn on UDP checksumming to avoid
   corrupted data not only with DNS but with other services that use UDP
   (like NFS).  Check with your operating system documentation to verify
   that UDP checksumming is enabled.

DNSは主としてUDP(ユーザー・データグラム・プロトコル)メッセージで作動します。 CPUサイクルを節約する取り組みでは、UDPチェックサムがオフにされている状態で、いくつかのUnixオペレーティングシステムが稼働しています。 この優劣は長い間、討論されています。 しかしながら、CPU速度の増加に従って、性能問題はますます重要でなくなります。 強く、奨励されて、あなたがDNSで避けるだけではなく、UDP(NFSのような)を使用する他のサービスでも崩壊したデータを避けるためにUDP checksummingをつけるのは、そうです。 オペレーティングシステムドキュメンテーションに問い合わせて、UDP checksummingが有効にされることを確かめてください。

References

参照

   [RFC 974] Partridge, C., "Mail routing and the domain system", STD
              14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.

[RFC974] ヤマウズラ、C.は「ルーティングとドメインシステムを郵送します」、STD14、RFC974、CSNET CIC BBN研究所Inc、1986年1月。

   [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC
              1033, USC/Information Sciences Institute, November 1987.

[RFC1033] Lottor、M、「操作が誘導するドメイン管理者」、USC/情報科学が1987年11月に設けるRFC1033。

   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, USC/Information Sciences Institute,
              November 1987.

Mockapetris、[RFC1034]P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日

   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
              Specification", STD 13, RFC 1035, USC/Information Sciences
              Institute, November 1987.

Mockapetris、[RFC1035]P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日

   [RFC 1123] Braden, R., "Requirements for Internet Hosts --
              Application and Support", STD 3, RFC 1123, IETF, October
              1989.

ブレーデン、[RFC1123]R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、IETF、10月1989日

   [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC
              1178, Integrated Systems Group/NIST, August 1990.

[RFC1178] リブスD. (FYI5、「あなたのコンピュータのための名前を選ぶ」RFC1178)はシステムグループ/NIST、1990年8月を統合しました。

   [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart,
              "New DNS RR Definitions", RFC 1183, October 1990.

[RFC1183] ウルマンとR.とMockapetrisとP.とMamakos、LとC.エバーハート、「新しいDNS RR定義」、RFC1183、1990年10月。

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

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

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

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

Barr                         Informational                     [Page 15]

RFC 1912                   Common DNS Errors               February 1996

一般的な[15ページ]RFC1912DNS誤り1996年2月の情報のバール

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

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

   [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN,
              November 1994.

[RFC1713] A.ロマン、「DNSデバッグのためのツール」、RFC1713、FCCN、1994年11月。

   [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND",
              Vixie Enterprises, July 1994.

[BOG] et Vixie、P、アル、「操作がひものために誘導するネームサーバ」、Vixieエンタープライズ、7月1994

5. Security Considerations

5. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

6. Author's Address

6. 作者のアドレス

   David Barr
   The Pennsylvania State University
   Department of Mathematics
   334 Whitmore Building
   University Park, PA 16802

PA ユニヴァーシティー・パーク、16802を築き上げるMathematics334ウィットモアのデヴィッド・バールペンシルバニア州立大学部

   Voice: +1 814 863 7374
   Fax: +1 814 863-8311
   EMail: barr@math.psu.edu

声: +1 814 863、7374Fax: +1 814 863-8311 メールしてください: barr@math.psu.edu

Barr                         Informational                     [Page 16]

バールInformationalです。[16ページ]