RFC1996 日本語訳
1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY).P. Vixie. August 1996. (Format: TXT=15247 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Vixie Request for Comments: 1996 ISC Updates: 1035 August 1996 Category: Standards Track
Vixieがコメントのために要求するワーキンググループP.をネットワークでつないでください: 1996のISCアップデート: 1035 1996年8月のカテゴリ: 標準化過程
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
ゾーン変化の迅速な通知のためのメカニズム(DNSは通知します)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data.
このメモはDNSのためにNOTIFY opcodeについて説明します。(マスターサーバは、DNSでマスターのデータを変えて、新しいデータを発見するために質問を開始するべきであると1セットの奴隷サーバに忠告します)。
1. Rationale and Scope
1. 原理と範囲
1.1. Slow propagation of new and changed data in a DNS zone can be due to a zone's relatively long refresh times. Longer refresh times are beneficial in that they reduce load on the master servers, but that benefit comes at the cost of long intervals of incoherence among authority servers whenever the zone is updated.
1.1. DNSゾーンでの新しくて変えられたデータの遅い伝播はゾーンのもののため比較的長い間回をリフレッシュすることであるかもしれません。 より長い間、リフレッシュしてください。マスターサーバで負荷を減少させるので、回は有益ですが、ゾーンをアップデートするときはいつも、その利益は権威サーバの中でしどろもどろの長い間隔の費用で来ます。
1.2. The DNS NOTIFY transaction allows master servers to inform slave servers when the zone has changed -- an interrupt as opposed to poll model -- which it is hoped will reduce propagation delay while not unduly increasing the masters' load. This specification only allows slaves to be notified of SOA RR changes, but the architechture of NOTIFY is intended to be extensible to other RR types.
1.2. DNS NOTIFYトランザクションはマスターの負荷を過度に増強していない間、ゾーンが、いつそれがどれであるかを変えたかを(投票モデルと対照的に中断)奴隷サーバに知らせるサーバが、意志が減少することを望んでいたマスターに伝播遅延を許容します。 この仕様は、奴隷がSOA RR変化について通知されるのを許容するだけですが、NOTIFYのarchitechtureが他のRRタイプにおいて広げることができることを意図します。
1.3. This document intentionally gives more definition to the roles of "Master," "Slave" and "Stealth" servers, their enumeration in NS RRs, and the SOA MNAME field. In that sense, this document can be considered an addendum to [RFC1035].
1.3. このドキュメントは故意に「マスター」の役割、「奴隷」と「こっそり」サーバ、NS RRsの彼らの列挙、およびSOA MNAME分野により多くの定義を与えます。 その意味で、[RFC1035]への付加物であるとこのドキュメントを考えることができます。
Vixie Standards Track [Page 1] RFC 1996 DNS NOTIFY August 1996
Vixie標準化過程[1ページ]RFC1996DNSは1996年8月に通知します。
2. Definitions and Invariants
2. 定義と不変式
2.1. The following definitions are used in this document:
2.1. 以下の定義は本書では使用されます:
Slave an authoritative server which uses zone transfer to retrieve the zone. All slave servers are named in the NS RRs for the zone.
身を粉にして働いてください。ゾーンを検索するゾーン転送を使用する正式のサーバ。 すべての奴隷サーバがNS RRsでゾーンにちなんで命名されます。
Master any authoritative server configured to be the source of zone transfer for one or more slave servers.
1つ以上の奴隷サーバのためのゾーン転送の源になるように構成されたあらゆる正式のサーバをマスタリングしてください。
Primary Master master server at the root of the zone transfer dependency graph. The primary master is named in the zone's SOA MNAME field and optionally by an NS RR. There is by definition only one primary master server per zone.
プライマリMasterはゾーン転送依存グラフの根でサーバをマスタリングします。 プライマリマスターはNS RRによってゾーンのSOA MNAME分野に任意に命名されます。 定義上、1ゾーンあたり1つのプライマリマスターサーバしかありません。
Stealth like a slave server except not listed in an NS RR for the zone. A stealth server, unless explicitly configured to do otherwise, will set the AA bit in responses and be capable of acting as a master. A stealth server will only be known by other servers if they are given static configuration data indicating its existence.
こっそりNS RRにゾーンに記載されていないのを除いた奴隷サーバのように。 別の方法でするために明らかに構成されないと、こっそりサーバは、AAビットを応答にはめ込んで、マスターとして務めることができるでしょう。 存在を示す静的なコンフィギュレーション・データをそれらに与える場合にだけ、他のサーバはこっそりサーバを知っているでしょう。
Notify Set set of servers to be notified of changes to some zone. Default is all servers named in the NS RRset, except for any server also named in the SOA MNAME. Some implementations will permit the name server administrator to override this set or add elements to it (such as, for example, stealth servers).
サーバのSetセットが何らかのゾーンへの変化について通知されるように通知してください。 デフォルトはまた、SOA MNAMEで指定されたどんなサーバ以外のサーバがNS RRsetで命名したすべてです。 いくつかの実装が、ネームサーバ管理者がそれ(例えば、こっそりサーバなどの)にこのセットをくつがえすか、または要素を加えることを許可するでしょう。
2.2. The zone's servers must be organized into a dependency graph such that there is a primary master, and all other servers must use AXFR or IXFR either from the primary master or from some slave which is also a master. No loops are permitted in the AXFR dependency graph.
2.2. プライマリマスターがあるように、依存グラフにゾーンのサーバを組織化しなければなりません、そして、他のすべてのサーバがプライマリマスターか奴隷からのまたマスターであるAXFRかIXFRを使用しなければなりません。 輪は全くAXFR依存グラフで受入れられません。
3. NOTIFY Message
3. メッセージに通知してください。
3.1. When a master has updated one or more RRs in which slave servers may be interested, the master may send the changed RR's name, class, type, and optionally, new RDATA(s), to each known slave server using a best efforts protocol based on the NOTIFY opcode.
3.1. マスターがどの奴隷サーバが関心があるので、マスターは変えられたRRの名前を送るかもしれません、クラス、タイプということであるかもしれないか、そして、任意に1RRsをアップデートしたとき、NOTIFY opcodeに基づく最善の努力プロトコルを使用するそれぞれの知られている奴隷サーバに、RDATA(s)です新しい。
3.2. NOTIFY uses the DNS Message Format, although it uses only a subset of the available fields. Fields not otherwise described herein are to be filled with binary zero (0), and implementations
3.2. 利用可能な分野の部分集合だけを使用しますが、NOTIFYはDNS Message Formatを使用します。 別の方法でここにバイナリーで満たされたことになっている状態で説明されなかった分野は(0)、および実装のゼロに合っています。
Vixie Standards Track [Page 2] RFC 1996 DNS NOTIFY August 1996
Vixie標準化過程[2ページ]RFC1996DNSは1996年8月に通知します。
must ignore all messages for which this is not the case.
これがそうでないすべてのメッセージを無視しなければなりません。
3.3. NOTIFY is similar to QUERY in that it has a request message with the header QR flag "clear" and a response message with QR "set". The response message contains no useful information, but its reception by the master is an indication that the slave has received the NOTIFY and that the master can remove the slave from any retry queue for this NOTIFY event.
3.3. NOTIFYはそれにはヘッダーQR旗が「明確であり」、QRがある応答メッセージが「設定されている」要求メッセージがあるという点においてQUERYと同様です。 応答メッセージは役に立つ情報を全く含んでいませんが、マスターによるレセプションは奴隷がNOTIFYを受け取って、マスターがこのNOTIFYイベントのためのどんな再試行待ち行列からも奴隷を外すことができるという指示です。
3.4. The transport protocol used for a NOTIFY transaction will be UDP unless the master has reason to believe that TCP is necessary; for example, if a firewall has been installed between master and slave, and only TCP has been allowed; or, if the changed RR is too large to fit in a UDP/DNS datagram.
3.4. マスターにTCPが必要であると信じる理由がない場合、NOTIFYトランザクションに使用されるトランスポート・プロトコルはUDPになるでしょう。 例えばファイアウォールがマスターと奴隷の間にインストールされて、TCPだけが許容されたなら。 または、変えられたRRであるなら、適任のコネへの大き過ぎるUDP/DNSはデータグラムですか?
3.5. If TCP is used, both master and slave must continue to offer name service during the transaction, even when the TCP transaction is not making progress. The NOTIFY request is sent once, and a "timeout" is said to have occurred if no NOTIFY response is received within a reasonable interval.
3.5. TCPが使用されているなら、マスターと奴隷の両方が、トランザクションの間、名前サービスを提供し続けなければなりません、TCPトランザクションが進展してさえいないとき。 一度NOTIFY要求を送ります、そして、妥当な間隔以内にNOTIFY応答を全く受けないなら、起こったと「タイムアウト」を言います。
3.6. If UDP is used, a master periodically sends a NOTIFY request to a slave until either too many copies have been sent (a "timeout"), an ICMP message indicating that the port is unreachable, or until a NOTIFY response is received from the slave with a matching query ID, QNAME, IP source address, and UDP source port number.
3.6. UDPが使用されているなら、マスターは(「タイムアウト」)、ポートが手が届かないのを示すICMPメッセージをあまりに多くのコピーに送ったか、または奴隷から合っている質問ID、QNAME、IPソースアドレス、およびUDPソースポート番号でNOTIFY応答を受けるまでNOTIFY要求を奴隷に定期的に送ります。
Note: The interval between transmissions, and the total number of retransmissions, should be operational parameters specifiable by the name server administrator, perhaps on a per-zone basis. Reasonable defaults are a 60 second interval (or timeout if using TCP), and a maximum of 5 retransmissions (for UDP). It is considered reasonable to use additive or exponential backoff for the retry interval.
以下に注意してください。 トランスミッションと、「再-トランスミッション」の総数の間隔はネームサーバ管理者が明記できる操作上のパラメタであるべきです、恐らく1ゾーンあたり1個のベースで。 合理的なデフォルトがa60 2番目の間隔である、(タイムアウト、TCPを使用します)、そして、最大5「再-トランスミッション」(UDPのための)。 それは再試行間隔の間、付加的であるか指数のbackoffを使用するのが妥当であると考えられます。
3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, ADCOUNT>=0. If ANCOUNT>0, then the answer section represents an unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>. A slave receiving such a hint is free to treat equivilence of this answer section with its local data as a "no further work needs to be done" indication. If ANCOUNT=0, or ANCOUNT>0 and the answer section differs from the slave's local data, then the slave should query its known masters to retrieve the new data.
3.7. NOTIFY要求にはQDCOUNT>0があって、ANCOUNT>は0、AUCOUNT>=0、ADCOUNT>=0と等しいです。 ANCOUNT>0であるなら、答え部はこの<QNAME、QCLASS、QTYPE>のために新しいRRsetにunsecureヒントを表します。 そのようなヒントを受ける奴隷は「さらなるされるべき仕事の必要性がありません」指示としてローカルのデータで自由にこの答え部のequivilenceを扱うことができます。 ANCOUNT=0である、ANCOUNT>0と答え部は奴隷のローカルのデータと異なっていて、次に、奴隷は、新しいデータを検索するために知られているマスターについて質問するべきです。
3.8. In no case shall the answer section of a NOTIFY request be used to update a slave's local data, or to indicate that a zone transfer needs to be undertaken, or to change the slave's zone refresh timers.
3.8. 奴隷のローカルのデータをアップデートするか、または転送が引き受けられるか、または奴隷のゾーンを変えるために必要とするゾーンがタイマをリフレッシュするのを示すのにNOTIFY要求の答え部を決して、使用しないものとします。
Vixie Standards Track [Page 3] RFC 1996 DNS NOTIFY August 1996
Vixie標準化過程[3ページ]RFC1996DNSは1996年8月に通知します。
Only a "data present; data same" condition can lead a slave to act differently if ANCOUNT>0 than it would if ANCOUNT=0.
「データプレゼント」だけ。 「データ同じ」状態は、奴隷がANCOUNT>0であるならANCOUNT=0であるならそうするだろうより異なって行動するように導くことができます。
3.9. This version of the NOTIFY specification makes no use of the authority or additional data sections, and so conforming implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting requests. Since a future revision of this specification may define a backwards compatible use for either or both of these sections, current implementations must ignore these sections, but not the entire message, if AUCOUNT>0 and/or ADCOUNT>0.
3.9. 権威か追加データの無駄はNOTIFY仕様のこのバージョンによってセクションにされます、そして、要求を伝えるとき、したがって、実装を従わせると、AUCOUNT=0とADCOUNT=0は設定されるべきです。 この仕様の今後の改正がこれらのセクションのどちらかか両方の遅れているコンパチブル使用を定義するかもしれないので、現在の実装は全体のメッセージではなく、これらのセクションを無視しなければなりません、AUCOUNT>0、そして/または、ADCOUNT>0であるなら。
3.10. If a slave receives a NOTIFY request from a host that is not a known master for the zone containing the QNAME, it should ignore the request and produce an error message in its operations log.
3.10. 奴隷がQNAMEを含むゾーンへの知られているマスターでないホストからNOTIFY要求を受け取るなら、それは、操作ログで要求を無視して、エラーメッセージを作り出すべきです。
Note: This implies that slaves of a multihomed master must either know their master by the "closest" of the master's interface addresses, or must know all of the master's interface addresses. Otherwise, a valid NOTIFY request might come from an address that is not on the slave's state list of masters for the zone, which would be an error.
以下に注意してください。 これは、「マルチ-家へ帰」っているマスターの奴隷がマスターの「最も近い」インターフェース・アドレスで彼らの主人を知らなければならないか、またはマスターのインターフェース・アドレスについてすべてを知らなければならないのを含意します。 さもなければ、有効なNOTIFY要求は奴隷の誤りであるだろうゾーンへのマスターの州のリストにないアドレスから来るかもしれません。
3.11. The only defined NOTIFY event at this time is that the SOA RR has changed. Upon completion of a NOTIFY transaction for QTYPE=SOA, the slave should behave as though the zone given in the QNAME had reached its REFRESH interval (see [RFC1035]), i.e., it should query its masters for the SOA of the zone given in the NOTIFY QNAME, and check the answer to see if the SOA SERIAL has been incremented since the last time the zone was fetched. If so, a zone transfer (either AXFR or IXFR) should be initiated.
3.11. 今回の唯一の定義されたNOTIFYイベントはSOA RRが変化したということです。 QTYPE=SOAであることのNOTIFYトランザクションの完成のときに、まるでQNAMEで与えられたゾーンがREFRESH間隔に達したかのように([RFC1035]を見てください)奴隷が振る舞うべきであり、すなわち、それは、NOTIFY QNAMEで与えられたゾーンのSOAのためにマスターについて質問して、ゾーンが最後の時間とって来られて以来SOA SERIALが増加されているかどうか確認するために答えをチェックするべきです。 そうだとすれば、ゾーン転送(AXFRかIXFRのどちらか)は起こされるべきです。
Note: Because a deep server dependency graph may have multiple paths from the primary master to any given slave, it is possible that a slave will receive a NOTIFY from one of its known masters even though the rest of its known masters have not yet updated their copies of the zone. Therefore, when issuing a QUERY for the zone's SOA, the query should be directed at the known master who was the source of the NOTIFY event, and not at any of the other known masters. This represents a departure from [RFC1035], which specifies that upon expiry of the SOA REFRESH interval, all known masters should be queried in turn.
以下に注意してください。 深いサーバ依存グラフにはプライマリマスターから与えられたどんな奴隷までも複数の経路があるかもしれないので、知られているマスターの残りがまだ彼らのゾーンのコピーをアップデートしていませんが、奴隷が知られているマスターのひとりからNOTIFYを受け取るのは、可能です。 したがって、ゾーンのSOAのためにQUERYを発行するとき、質問は他の知られているマスターのどれかではなく、NOTIFYイベントの源であった知られているマスターに向けられるべきです。 これは[RFC1035]から出発を表します。(それは、SOA REFRESH間隔の満期にすべての知られているマスターが順番に質問されるべきであると指定します)。
3.12. If a NOTIFY request is received by a slave who does not implement the NOTIFY opcode, it will respond with a NOTIMP (unimplemented feature error) message. A master server who receives such a NOTIMP should consider the NOTIFY transaction complete for
3.12. NOTIFY要求がNOTIFY opcodeを実装しない奴隷によって受け取られると、それはNOTIMP(特徴誤りを非実装した)メッセージで応じるでしょう。 そのようなNOTIMPを受けるマスターサーバは、NOTIFYトランザクションが完全であると考えるべきです。
Vixie Standards Track [Page 4] RFC 1996 DNS NOTIFY August 1996
Vixie標準化過程[4ページ]RFC1996DNSは1996年8月に通知します。
that slave.
その奴隷。
4. Details and Examples
4. 詳細と例
4.1. Retaining query state information across host reboots is optional, but it is reasonable to simply execute an SOA NOTIFY transaction on each authority zone when a server first starts.
4.1. ホストリブートの向こう側に質問州の情報を保有するのは任意ですが、サーバが最初に始まるとき、それぞれの権威ゾーンで単にSOA NOTIFYトランザクションを実行するのは妥当です。
4.2. Each slave is likely to receive several copies of the same NOTIFY request: One from the primary master, and one from each other slave as that slave transfers the new zone and notifies its potential peers. The NOTIFY protocol supports this multiplicity by requiring that NOTIFY be sent by a slave/master only AFTER it has updated the SOA RR or has determined that no update is necessary, which in practice means after a successful zone transfer. Thus, barring delivery reordering, the last NOTIFY any slave receives will be the one indicating the latest change. Since a slave always requests SOAs and AXFR/IXFRs only from its known masters, it will have an opportunity to retry its QUERY for the SOA after each of its masters have completed each zone update.
4.2. それぞれの奴隷は数個のコピーの同じNOTIFY要求を受け取りそうです: プライマリマスターからの1、その奴隷が新しいゾーンを移して、潜在的同輩に通知するとき、互いからの1つは身を粉にして働きます。 NOTIFYによる奴隷/マスターAFTERだけによって送られて、SOA RRをアップデートしたか、またはどんなアップデートも必要でないことを決定したという(うまくいっているゾーンの後の習慣手段で移されます)ことであることを必要とすることによって、NOTIFYプロトコルはこの多様性をサポートします。 したがって、配送再命令を除いて、どんな奴隷も受け取る最後のNOTIFYは最新の変化を示すものになるでしょう。 奴隷が単に知られているマスターからSOAsとAXFR/IXFRsをいつも要求するので、それには、マスター各人がそれぞれのゾーンアップデートを終了した後にSOAのためにQUERYを再試行する機会があるでしょう。
4.3. If a master server seeks to avoid causing a large number of simultaneous outbound zone transfers, it may delay for an arbitrary length of time before sending a NOTIFY message to any given slave. It is expected that the time will be chosen at random, so that each slave will begin its transfer at a unique time. The delay shall not in any case be longer than the SOA REFRESH time.
4.3. マスターサーバが、多くの同時の外国行きのゾーン転送を引き起こすのを避けようとするなら、どんな与えられた奴隷にもNOTIFYメッセージを送る前に、それは任意の長さの時に延着するかもしれません。 時間が無作為に選ばれると予想されます、各奴隷がユニークな時に転送を始めるように。 どのような場合でも、遅れはSOA REFRESH時間ほど、より長くならないでしょう。
Note: This delay should be a parameter that each primary master name server can specify, perhaps on a per-zone basis. Random delays of between 30 and 60 seconds would seem adequate if the servers share a LAN and the zones are of moderate size.
以下に注意してください。 この遅れはそれぞれのプライマリマスターネームサーバが恐らく1ゾーンあたり1個のベースで指定できるパラメタであるべきです。 30〜60秒の無作為の遅れはサーバがLANを共有して、ゾーンが適度のサイズのものであるなら適切に見えるでしょう。
4.4. A slave which receives a valid NOTIFY should defer action on any subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has completed the transaction begun by the first NOTIFY. This duplicate rejection is necessary to avoid having multiple notifications lead to pummeling the master server.
4.4. 有効なNOTIFYを受け取る奴隷は同じ<QNAME、QCLASS、QTYPE>とどんなその後のNOTIFYへの最初のNOTIFYによって始められた取引を完了するまでの動作も延期するべきです。 この写し拒絶が、複数の通知が、マスターサーバをこぶしで打つのに通じさせるのを避けるのに必要です。
Vixie Standards Track [Page 5] RFC 1996 DNS NOTIFY August 1996
Vixie標準化過程[5ページ]RFC1996DNSは1996年8月に通知します。
4.5 Zone has Updated on Primary Master
4.5ゾーンは予備選挙でマスターをアップデートしました。
Primary master sends a NOTIFY request to all servers named in Notify Set. The NOTIFY request has the following characteristics:
プライマリマスターはNotify Setで指定されたすべてのサーバにNOTIFY要求を送ります。 NOTIFY要求には、以下の特性があります:
query ID: (new) op: NOTIFY (4) resp: NOERROR flags: AA qcount: 1 qname: (zone name) qclass: (zone class) qtype: T_SOA
IDについて質問してください: (新しい)です。 オプアート: NOTIFY(4)resp: NOERRORは弛みます: AA qcount: 1qname: (ゾーン名) qclass: (ゾーンのクラス) qtype: T_SOA
4.6 Zone has Updated on a Slave that is also a Master
4.6ゾーンはまたMasterであるSlaveにUpdatedを持っています。
As above in 4.5, except that this server's Notify Set may be different from the Primary Master's due to optional static specification of local stealth servers.
4.5で上です、このサーバのNotify Setが異なるかもしれないのを除いて、Primary Masterの支払われるべきものから任意の静的なローカルのこっそりサーバの仕様まで異なってください。
4.7 Slave Receives a NOTIFY Request from a Master
4.7奴隷が受信する、aはマスターから要求に通知します。
When a slave server receives a NOTIFY request from one of its locally designated masters for the zone enclosing the given QNAME, with QTYPE=SOA and QR=0, it should enter the state it would if the zone's refresh timer had expired. It will also send a NOTIFY response back to the NOTIFY request's source, with the following characteristics:
奴隷サーバが局所的に指定されたマスターのひとりからNOTIFY要求をゾーンに受け取るとき、ゾーンのものがタイマをリフレッシュするならそれがそうする状態は期限が切れて、それがQTYPE=SOAとQR=0と共に入るべきである与えられたQNAMEを同封しました。 また、それは以下の特性でNOTIFY要求のソースにNOTIFY応答を送り返すでしょう:
query ID: (same) op: NOTIFY (4) resp: NOERROR flags: QR AA qcount: 1 qname: (zone name) qclass: (zone class) qtype: T_SOA
IDについて質問してください: (同じこと) オプアート: NOTIFY(4)resp: NOERRORは弛みます: QR AA qcount: 1qname: (ゾーン名) qclass: (ゾーンのクラス) qtype: T_SOA
This is intended to be identical to the NOTIFY request, except that the QR bit is also set. The query ID of the response must be the same as was received in the request.
また、QRビットが設定されるのを除いて、これがNOTIFY要求と同じであることを意図します。 要求で応答のIDが同じであるに違いない質問を受けました。
4.8 Master Receives a NOTIFY Response from Slave
4.8マスターが受信する、aは奴隷から応答に通知します。
When a master server receives a NOTIFY response, it deletes this query from the retry queue, thus completing the "notification process" of "this" RRset change to "that" server.
マスターサーバがNOTIFY応答を受けるとき、再試行待ち行列からこの質問を削除します、その結果、「that」のサーバへの「this」のRRset変化の「通知プロセス」を完成します。
Vixie Standards Track [Page 6] RFC 1996 DNS NOTIFY August 1996
Vixie標準化過程[6ページ]RFC1996DNSは1996年8月に通知します。
5. Security Considerations
5. セキュリティ問題
We believe that the NOTIFY operation's only security considerations are:
私たちは、NOTIFY操作の唯一のセキュリティ問題が以下の通りであると信じています。
1. That a NOTIFY request with a forged IP/UDP source address can cause a slave to send spurious SOA queries to its masters, leading to a benign denial of service attack if the forged requests are sent very often.
1. 奴隷が偽造IP/UDPソースアドレスによるNOTIFY要求で偽物のSOAを送ることができるのが偽造要求が頻繁に送られるかどうかをサービス攻撃の優しい否定に通じるマスターに質問します。
2. That TCP spoofing could be used against a slave server given NOTIFY as a means of synchronizing an SOA query and UDP/DNS spoofing as a means of forcing a zone transfer.
2. ゾーン転送を強制する手段としてSOA質問とUDP/DNSスプーフィングを同時にさせる手段としてのNOTIFYを考えて、奴隷サーバに対してそのTCPスプーフィングを使用できました。
6. References
6. 参照
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[IXFR] Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
[IXFR] 太田、M.、「増加のゾーン転送」、RFC1995、1996年8月。
7. Author's Address
7. 作者のアドレス
Paul Vixie Internet Software Consortium Star Route Box 159A Woodside, CA 94062
ポールVixieインターネットソフトウェア共同体星のルート箱の159Aウッドサイド、カリフォルニア 94062
Phone: +1 415 747 0204 EMail: paul@vix.com
以下に電話をしてください。 +1 0204年の415 747メール: paul@vix.com
Vixie Standards Track [Page 7]
Vixie標準化過程[7ページ]
一覧
スポンサーリンク