RFC1995 日本語訳
1995 Incremental Zone Transfer in DNS. M. Ohta. August 1996. (Format: TXT=16810 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Ohta Request for Comments: 1995 Tokyo Institute of Technology Updates: 1035 August 1996 Category: Standards Track
コメントを求めるワーキンググループM.太田の要求をネットワークでつないでください: 1995の東京工業大学アップデート: 1035 1996年8月のカテゴリ: 標準化過程
Incremental Zone Transfer in DNS
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 document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism.
このドキュメントは、増加のゾーン転送(IXFR)メカニズムを提供するためにDNSプロトコルに拡大を提案します。
1. Introduction
1. 序論
For rapid propagation of changes to a DNS database [STD13], it is necessary to reduce latency by actively notifying servers of the change. This is accomplished by the NOTIFY extension of the DNS [NOTIFY].
DNSデータベース[STD13]への変化の急速な伝播に、活発に変化のサーバに通知することによってレイテンシを減少させるのが必要です。 これはDNS[NOTIFY]のNOTIFY拡張子で達成されます。
The current full zone transfer mechanism (AXFR) is not an efficient means to propagate changes to a small part of a zone, as it transfers the entire zone file.
現在の完全なゾーントランスファ・メカニズム(AXFR)はゾーンの小さい部分への変化を伝播する効率的な手段ではありません、全体のゾーンファイルを移すとき。
Incremental transfer (IXFR) as proposed is a more efficient mechanism, as it transfers only the changed portion(s) of a zone.
ゾーンの変化分だけを移すのに従って、提案されるとしての増加の転送(IXFR)は、より効率的なメカニズムです。
In this document, a secondary name server which requests IXFR is called an IXFR client and a primary or secondary name server which responds to the request is called an IXFR server.
本書では、IXFRを要求するセカンダリネームサーバはIXFRクライアントと呼ばれます、そして、要求に応じるプライマリの、または、セカンダリのネームサーバはIXFRサーバと呼ばれます。
2. Brief Description of the Protocol
2. プロトコルの簡単な説明
If an IXFR client, which likely has an older version of a zone, thinks it needs new information about the zone (typically through SOA refresh timeout or the NOTIFY mechanism), it sends an IXFR message containing the SOA serial number of its, presumably outdated, copy of the zone.
IXFRクライアント(おそらくゾーンの旧式のバージョンを持っている)が、ゾーン(通常SOAを通して、タイムアウトかNOTIFYメカニズムをリフレッシュする)に関して、SOA通し番号を含むIXFRメッセージを送るという新情報を必要とすると考える、それ、おそらく、時代遅れであり、ゾーンをコピーしてください。
Ohta Standards Track [Page 1] RFC 1995 Incremental Zone Transfer in DNS August 1996
太田Standardsは1996年8月にDNSのRFC1995の増加のゾーン転送を追跡します[1ページ]。
An IXFR server should keep record of the newest version of the zone and the differences between that copy and several older versions. When an IXFR request with an older version number is received, the IXFR server needs to send only the differences required to make that version current. Alternatively, the server may choose to transfer the entire zone just as in a normal full zone transfer.
IXFRサーバはゾーンの最も新しいバージョンとそのコピーといくつかの旧式のバージョンの違いに関する記録をつけるべきです。 旧式のバージョン番号があるIXFR要求が受信されているとき、IXFRサーバは、そのバージョンを現在にするのに必要である違いだけを送る必要があります。 あるいはまた、サーバは、ちょうど通常の完全なゾーン転送のように全体のゾーンを移すのを選ぶかもしれません。
When a zone has been updated, it should be saved in stable storage before the new version is used to respond to IXFR (or AXFR) queries. Otherwise, if the server crashes, data which is no longer available may have been distributed to secondary servers, which can cause persistent database inconsistencies.
ゾーンをアップデートしたとき、IXFR(または、AXFR)質問に応じるのに新しいバージョンを使用する前に安定貯蔵でそれを保存するべきです。 さもなければ、サーバがダウンするなら、もう得ることができないデータはセカンダリサーバに分配されたかもしれません。(セカンダリサーバは永続的なデータベース矛盾を引き起こす場合があります)。
If an IXFR query with the same or newer version number than that of the server is received, it is replied to with a single SOA record of the server's current version, just as in AXFR.
サーバのものより同じであるか新しいバージョン番号があるIXFR質問が受け取られているなら、それはサーバの最新版のただ一つのSOA記録で答えられます、ちょうどAXFRのように。
Transport of a query may be by either UDP or TCP. If an IXFR query is via UDP, the IXFR server may attempt to reply using UDP if the entire response can be contained in a single DNS packet. If the UDP reply does not fit, the query is responded to with a single SOA record of the server's current version to inform the client that a TCP query should be initiated.
質問の輸送がUDPかTCPのどちらかであるかもしれません。 UDPを通してIXFR質問があるなら、IXFRサーバは、単一のDNSパケットに全体の応答を含むことができるならUDPを使用することで返答するのを試みるかもしれません。 UDP回答が合わないなら、サーバの最新版のただ一つのSOA記録で質問に応じて、TCP質問が開始されるべきであることをクライアントに知らせます。
Thus, a client should first make an IXFR query using UDP. If the query type is not recognized by the server, an AXFR (preceded by a UDP SOA query) should be tried, ensuring backward compatibility. If the query response is a single packet with the entire new zone, or if the server does not have a newer version than the client, everything is done. Otherwise, a TCP IXFR query should be tried.
したがって、クライアントは、最初に、UDPを使用することでIXFR質問をするべきです。 質問タイプがサーバによって見分けられないなら、AXFR(UDP SOA質問で、先行されている)は試みられるべきです、後方の互換性を確実にして。 サーバにクライアントより新しいバージョンがないなら質問応答が全体の新しいゾーンがある単一のパケットであるなら、すべてをします。 さもなければ、TCP IXFR質問は試みられるべきです。
To ensure integrity, servers should use UDP checksums for all UDP responses. A cautious client which receives a UDP packet with a checksum value of zero should ignore the result and try a TCP IXFR instead.
保全を確実にするために、サーバはすべてのUDP応答にUDPチェックサムを使用するべきです。 ゼロのチェックサム値でUDPパケットを受ける用心深いクライアントは、結果を無視して、代わりにTCP IXFRを試みるべきです。
The query type value of IXFR assigned by IANA is 251.
IANAによって割り当てられたIXFRの質問タイプ価値は251です。
3. Query Format
3. 質問形式
The IXFR query packet format is the same as that of a normal DNS query, but with the query type being IXFR and the authority section containing the SOA record of client's version of the zone.
IXFR質問パケット・フォーマットは、通常のDNS質問のものと同じですが、質問タイプがIXFRであり、権威部がクライアントのゾーンのバージョンに関するSOA記録を含んでいて、同じです。
Ohta Standards Track [Page 2] RFC 1995 Incremental Zone Transfer in DNS August 1996
太田Standardsは1996年8月にDNSのRFC1995の増加のゾーン転送を追跡します[2ページ]。
4. Response Format
4. 応答形式
If incremental zone transfer is not available, the entire zone is returned. The first and the last RR of the response is the SOA record of the zone. I.e. the behavior is the same as an AXFR response except the query type is IXFR.
増加のゾーン転送が利用可能でないなら、全体のゾーンを返します。 応答の1番目と最後のRRはゾーンに関するSOA記録です。 すなわち、振舞いは質問タイプ以外のAXFR応答がIXFRであるのと同じです。
If incremental zone transfer is available, one or more difference sequences is returned. The list of difference sequences is preceded and followed by a copy of the server's current version of the SOA.
増加のゾーン転送が利用可能であるなら、1つ以上の階差数列が返されます。 サーバのSOAの最新版のコピーは、階差数列のリストに先行されていて、支えています。
Each difference sequence represents one update to the zone (one SOA serial change) consisting of deleted RRs and added RRs. The first RR of the deleted RRs is the older SOA RR and the first RR of the added RRs is the newer SOA RR.
各階差数列は、削除されたRRsと加えられたRRsから成りながら、ゾーン(1回のSOA系列変化)に1つのアップデートを表します。 削除されたRRsの最初のRRは、より古いSOA RRです、そして、加えられたRRsの最初のRRは、より新しいSOA RRです。
Modification of an RR is performed first by removing the original RR and then adding the modified one.
RRの変更は、最初に、オリジナルのRRを取り外して、次に、変更されたものを加えることによって、実行されます。
The sequences of differential information are ordered oldest first newest last. Thus, the differential sequences are the history of changes made since the version known by the IXFR client up to the server's current version.
最も古い1番目に新しい最終は特異な情報の系列に命令されます。 したがって、特異な系列はIXFRクライアントによってサーバの最新版まで知られていたバージョン以来行われた変更の歴史です。
RRs in the incremental transfer messages may be partial. That is, if a single RR of multiple RRs of the same RR type changes, only the changed RR is transferred.
増加の転送メッセージのRRsは部分的であるかもしれません。 すなわち、同じRRタイプの複数のRRsの独身のRRが変化するなら、変えられたRRだけがわたっています。
An IXFR client, should only replace an older version with a newer version after all the differences have been successfully processed.
IXFRクライアント、首尾よくすべての違いを処理してある後に旧式のバージョンをより新しいバージョンに取り替えるだけであるべきです。
An incremental response is different from that of a non-incremental response in that it begins with two SOA RRs, the server's current SOA followed by the SOA of the client's version which is about to be replaced.
増加の応答は非増加の応答のものと2SOA RRsと共に始まるという点において異なっています、とサーバの現在のSOAが取り替えられようとしているクライアントのバージョンのSOAで続きました。
5. Purging Strategy
5. 除く戦略
An IXFR server can not be required to hold all previous versions forever and may delete them anytime. In general, there is a trade-off between the size of storage space and the possibility of using IXFR.
IXFRサーバは、いつまでもすべての旧バージョンを保持するのが必要であることができなく、いつでもそれらを削除するかもしれません。 一般に、集積スペースのサイズとIXFRを使用する可能性の間には、トレードオフがあります。
Information about older versions should be purged if the total length of an IXFR response would be longer than that of an AXFR response. Given that the purpose of IXFR is to reduce AXFR overhead, this strategy is quite reasonable. The strategy assures that the amount of storage required is at most twice that of the current zone information.
旧式のバージョンに関する情報はそれより長い間IXFR応答の全長がAXFR応答のものであるなら掃除されるべきです。 IXFRの目的がAXFRオーバーヘッドを下げることであるなら、この戦略はかなり合理的です。 戦略は、必要であるストレージの量が高々現在のゾーン情報のものの2倍であることを保証します。
Ohta Standards Track [Page 3] RFC 1995 Incremental Zone Transfer in DNS August 1996
太田Standardsは1996年8月にDNSのRFC1995の増加のゾーン転送を追跡します[3ページ]。
Information older than the SOA expire period may also be purged.
また、SOAが期間を吐き出すより古い情報は掃除されるかもしれません。
6. Optional Condensation of Multiple Versions
6. 複数のバージョンの任意の凝縮
An IXFR server may optionally condense multiple difference sequences into a single difference sequence, thus, dropping information on intermediate versions.
その結果、IXFRサーバは、中間的バージョンの情報を下げながら、任意に複数の階差数列をただ一つの階差数列に凝縮するかもしれません。
This may be beneficial if a lot of versions, not all of which are useful, are generated. For example, if multiple ftp servers share a single DNS name and the IP address associated with the name is changed once a minute to balance load between the ftp servers, it is not so important to keep track of all the history of changes.
多くのバージョン(それのすべてでないのが役に立つ)が発生しているなら、これは有益であるかもしれません。 例えば、ただ一つのDNS名とIPアドレスが存在というバランスをとるために1分に一度変える名前に関連づけた複数のftpサーバ株がftpサーバの間でロードされるなら、変化のすべての歴史の動向をおさえるのはそれほど重要ではありません。
But, this feature may not be so useful if an IXFR client has access to two IXFR servers: A and B, with inconsistent condensation results. The current version of the IXFR client, received from server A, may be unknown to server B. In such a case, server B can not provide incremental data from the unknown version and a full zone transfer is necessary.
しかし、IXFRクライアントが2つのIXFRサーバに近づく手段を持っているなら、この特徴はそれほど役に立たないかもしれません: 矛盾した凝縮結果があるAとB。 サーバB.Inへの未知がそのような場合であったかもしれないならサーバAから受け取られたIXFRクライアントの最新版、サーバBは未知のバージョンから増加のデータを提供できません、そして、完全なゾーン転送が必要です。
Condensation is completely optional. Clients can't detect from the response whether the server has condensed the reply or not.
凝縮は完全に任意です。 クライアントは、応答からサーバが回答を凝縮したかどうか検出できません。
For interoperability, IXFR servers, including those without the condensation feature, should not flag an error even if it receives a client's IXFR request with a unknown version number and should, instead, attempt to perform a full zone transfer.
相互運用性のために、凝縮機能なしでものを含むIXFRサーバは、未知のバージョン番号でクライアントのIXFR要求を受け取っても誤りに旗を揚げさせるべきでなくて、代わりに完全なゾーン転送を実行するのを試みるべきです。
7. Example
7. 例
Given the following three generations of data with the current serial number of 3,
3の現在の通し番号がある以下の三代のデータを与えます。
JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
1 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP. IN A 133.69.136.1
NEZU.JAIN.AD.JP. IN A 133.69.136.5
JAIN.AD.JP。 IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp。 ( 1 600 600 3600000 604800) ナノ秒NS.JAIN.AD.JPで。 NS.JAIN.AD.JP。 IN A、133.69 .136 .1 NEZU.JAIN.AD.JP。 IN A133.69.136、.5
NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added.
そして、NEZU.JAIN.AD.JP、取り除く、ジャイナ教のBB.JAIN.AD.JP加えられます。
jain.ad.jp. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
2 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP. IN A 133.69.136.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4
IN A 192.41.197.2
jain.ad.jp。 IN SOA ns.jain.ad.jp mohta.jain.ad.jp。 ( 2 600 600 3600000 604800) ナノ秒NS.JAIN.AD.JPで。 NS.JAIN.AD.JP。 IN A、133.69 .136 .1 ジャイナ教徒-BB.JAIN.AD.JP。 IN A133.69.136.4IN A192.41.197、.2
Ohta Standards Track [Page 4] RFC 1995 Incremental Zone Transfer in DNS August 1996
太田Standardsは1996年8月にDNSのRFC1995の増加のゾーン転送を追跡します[4ページ]。
One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.
ジャイナ教のBB.JAIN.AD.JPのIPアドレスの1つ、変えます。
JAIN.AD.JP. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
3 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP. IN A 133.69.136.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3
IN A 192.41.197.2
JAIN.AD.JP。 IN SOA ns.jain.ad.jp mohta.jain.ad.jp。 ( 3 600 600 3600000 604800) ナノ秒NS.JAIN.AD.JPで。 NS.JAIN.AD.JP。 IN A、133.69 .136 .1 ジャイナ教徒-BB.JAIN.AD.JP。 IN A133.69.136.3IN A192.41.197、.2
The following IXFR query
以下のIXFR質問
+---------------------------------------------------+
Header | OPCODE=SQUERY |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | JAIN.AD.JP. IN SOA serial=1 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
+---------------------------------------------------+ ヘッダー| OPCODE=SQUERY| +---------------------------------------------------+ 問題| QNAME=JAIN.AD.JP、QCLASSはIN、QTYPE=IXFRと等しいです。| +---------------------------------------------------+ 答え| <の空の>。| +---------------------------------------------------+ 権威| JAIN.AD.JP。 IN SOAシリーズ=1| +---------------------------------------------------+追加しています。| <の空の>。| +---------------------------------------------------+
could be replied to with the following full zone transfer message:
以下の完全なゾーン転送メッセージで答えることができました:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
| JAIN.AD.JP. IN NS NS.JAIN.AD.JP. |
| NS.JAIN.AD.JP. IN A 133.69.136.1 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
| JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
+---------------------------------------------------+ ヘッダー| OPCODE=SQUERY、応答| +---------------------------------------------------+ 問題| QNAME=JAIN.AD.JP、QCLASSはIN、QTYPE=IXFRと等しいです。| +---------------------------------------------------+ 答え| JAIN.AD.JP。 IN SOAシリーズ=3| | JAIN.AD.JP。 ナノ秒NS.JAIN.AD.JPで。 | | NS.JAIN.AD.JP。 IN A133.69.136、.1| | ジャイナ教徒-BB.JAIN.AD.JP。 IN A133.69.136、.3| | ジャイナ教徒-BB.JAIN.AD.JP。 IN A192.41.197、.2| | JAIN.AD.JP。 IN SOAシリーズ=3| +---------------------------------------------------+ 権威| <の空の>。| +---------------------------------------------------+追加しています。| <の空の>。| +---------------------------------------------------+
Ohta Standards Track [Page 5] RFC 1995 Incremental Zone Transfer in DNS August 1996
太田Standardsは1996年8月にDNSのRFC1995の増加のゾーン転送を追跡します[5ページ]。
or with the following incremental message:
または、以下が増加で、通信してください:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
| JAIN.AD.JP. IN SOA serial=1 |
| NEZU.JAIN.AD.JP. IN A 133.69.136.5 |
| JAIN.AD.JP. IN SOA serial=2 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
| JAIN.AD.JP. IN SOA serial=2 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 |
| JAIN.AD.JP. IN SOA serial=3 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
| JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
+---------------------------------------------------+ ヘッダー| OPCODE=SQUERY、応答| +---------------------------------------------------+ 問題| QNAME=JAIN.AD.JP、QCLASSはIN、QTYPE=IXFRと等しいです。| +---------------------------------------------------+ 答え| JAIN.AD.JP。 IN SOAシリーズ=3| | JAIN.AD.JP。 IN SOAシリーズ=1| | NEZU.JAIN.AD.JP。 IN A133.69.136、.5| | JAIN.AD.JP。 IN SOAシリーズ=2| | ジャイナ教徒-BB.JAIN.AD.JP。 IN A133.69.136、.4| | ジャイナ教徒-BB.JAIN.AD.JP。 IN A192.41.197、.2| | JAIN.AD.JP。 IN SOAシリーズ=2| | ジャイナ教徒-BB.JAIN.AD.JP。 IN A133.69.136、.4| | JAIN.AD.JP。 IN SOAシリーズ=3| | ジャイナ教徒-BB.JAIN.AD.JP。 IN A133.69.136、.3| | JAIN.AD.JP。 IN SOAシリーズ=3| +---------------------------------------------------+ 権威| <の空の>。| +---------------------------------------------------+追加しています。| <の空の>。| +---------------------------------------------------+
or with the following condensed incremental message:
または、以下で、増加のメッセージは凝縮していました:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
| JAIN.AD.JP. IN SOA serial=1 |
| NEZU.JAIN.AD.JP. IN A 133.69.136.5 |
| JAIN.AD.JP. IN SOA serial=3 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
| JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
+---------------------------------------------------+ ヘッダー| OPCODE=SQUERY、応答| +---------------------------------------------------+ 問題| QNAME=JAIN.AD.JP、QCLASSはIN、QTYPE=IXFRと等しいです。| +---------------------------------------------------+ 答え| JAIN.AD.JP。 IN SOAシリーズ=3| | JAIN.AD.JP。 IN SOAシリーズ=1| | NEZU.JAIN.AD.JP。 IN A133.69.136、.5| | JAIN.AD.JP。 IN SOAシリーズ=3| | ジャイナ教徒-BB.JAIN.AD.JP。 IN A133.69.136、.3| | ジャイナ教徒-BB.JAIN.AD.JP。 IN A192.41.197、.2| | JAIN.AD.JP。 IN SOAシリーズ=3| +---------------------------------------------------+ 権威| <の空の>。| +---------------------------------------------------+追加しています。| <の空の>。| +---------------------------------------------------+
Ohta Standards Track [Page 6] RFC 1995 Incremental Zone Transfer in DNS August 1996
太田Standardsは1996年8月にDNSのRFC1995の増加のゾーン転送を追跡します[6ページ]。
or, if UDP packet overflow occurs, with the following message:
または、UDPであるなら、パケットオーバーフローは以下のメッセージで起こります:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
+---------------------------------------------------+ ヘッダー| OPCODE=SQUERY、応答| +---------------------------------------------------+ 問題| QNAME=JAIN.AD.JP、QCLASSはIN、QTYPE=IXFRと等しいです。| +---------------------------------------------------+ 答え| JAIN.AD.JP。 IN SOAシリーズ=3| +---------------------------------------------------+ 権威| <の空の>。| +---------------------------------------------------+追加しています。| <の空の>。| +---------------------------------------------------+
8. Acknowledgements
8. 承認
The original idea of IXFR was conceived by Anant Kumar, Steve Hotz and Jon Postel.
IXFRの着想はAnantクマー、スティーブHotz、およびジョン・ポステルによって発想されました。
For the refinement of the protocol and documentation, many people have contributed including, but not limited to, Anant Kumar, Robert Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the members of the IETF DNSIND working group.
プロトコルとドキュメンテーションの気品のために、多くの人々が包含、他、Anantクマー、ロバートAustein、ポールVixie、ランディ・ブッシュ、マーク・アンドリュース、ロバートElz、およびIETF DNSINDワーキンググループのメンバーを寄付しました。
9. References
9. 参照
[NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt Notification of Zone Changes", RFC 1996, August 1996.
[通知します] Vixie、P.、「DNSは通知します」。 「ゾーン変化の迅速な通知のためのメカニズム」、RFC1996、1996年8月。
[STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and RFC 1035), November 1987.
[STD13] MockapetrisとP.と「ドメインネームシステム」とSTD13とRFC1034とRFC1035)、1987年11月。
10. Security Considerations
10. セキュリティ問題
Though DNS is related to several security problems, no attempt is made to fix them in this document.
いくつかの警備上の問題にDNSに関連しますが、本書ではそれらを修理するのを試みを全くしません。
This document is believed to introduce no additional security problems to the current DNS protocol.
このドキュメントが現在のDNSプロトコルに追加担保問題を全く取り入れないと信じられています。
Ohta Standards Track [Page 7] RFC 1995 Incremental Zone Transfer in DNS August 1996
太田Standardsは1996年8月にDNSのRFC1995の増加のゾーン転送を追跡します[7ページ]。
11. Author's Address
11. 作者のアドレス
Masataka Ohta Computer Center Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN
Masataka太田コンピュータセンター東京工業大学2-12-1、大岡山、目黒区、日本東京152
Phone: +81-3-5734-3299 Fax: +81-3-5734-3415 EMail: mohta@necom830.hpcl.titech.ac.jp
以下に電話をしてください。 +81-3-5734-3299 Fax: +81-3-5734-3415 メールしてください: mohta@necom830.hpcl.titech.ac.jp
Ohta Standards Track [Page 8]
太田標準化過程[8ページ]
一覧
スポンサーリンク
