EDNS0

1. RFC 6891 における EDNS0

RFC 2671 -> 6891 https://tools.ietf.org/html/rfc6891

主な拡張は以下。 メッセージヘッダの拡張なども含まれているが、以下をとりあえずピックアップ。

  • UDP ペイロードサイズの拡張

  • ラベルの拡張

  • OPT Pseudo-RR

1.1. UDP ペイロードサイズの拡張

当初は 512 バイトを想定。(RFC 791 の IPv4 の定義の影響) 1 パケットで送受信できるため。

RFC 2671 で最初に拡張された。(最大 65535 バイト、 Ethernet 接続では 1280 バイトくらいがいい) RFC 6891 では 1280-1410 程度が妥当であり、最大でも 4096 くらいにするのがいいと述べられている。

6.2.5. Payload Size Selection

A requestor MAY choose to implement a fallback to smaller advertised sizes to work around firewall or other network limitations. A requestor SHOULD choose to use a fallback mechanism that begins with a large size, such as 4096. If that fails, a fallback around the range of 1280-1410 bytes SHOULD be tried, as it has a reasonable chance to fit within a single Ethernet frame. Failing that, a requestor MAY choose a 512-byte packet, which with large answers may cause a TCP retry.

1.2. ラベルの拡張

5. Extended Label Types

The first octet in the on-the-wire representation of a DNS label specifies the label type; the basic DNS specification [RFC1035] dedicates the 2 most significant bits of that octet for this purpose.

[RFC2671] defined DNS label type 0b01 for use as an indication for extended label types. A specific extended label type was selected by the 6 least significant bits of the first octet. Thus, extended label types were indicated by the values 64-127 (0b01xxxxxx) in the first octet of the label.

Extended label types are extremely difficult to deploy due to lack of support in clients and intermediate gateways, as described in [RFC3363], which moved [RFC2673] to Experimental status; and [RFC3364], which describes the pros and cons. As such, proposals that contemplate extended labels SHOULD weigh this deployment cost against the possibility of implementing functionality in other ways.

Finally, implementations MUST NOT generate or pass Binary Labels in their communications, as they are now deprecated.

3 - Extended Label Types

3.1. The "0 1" label type will now indicate an extended label type, whose value is encoded in the lower six bits of the first octet of a label. All subsequently developed label types should be encoded using an extended label type.

3.2. The "1 1 1 1 1 1" extended label type will be reserved for future expansion of the extended label type code space.

実装されてないのでどうでもいいっちゃどうでもいい。

ドメインラベルの最初の2ビットはラベルの種類を表現するために用いられている。[RFC1035 4.1.4]

4.1.4. Message compression | RFC 1035

The first two bits are ones. This allows a pointer to be distinguished from a label, since the label must begin with two zero bits because labels are restricted to 63 octets or less. (The 10 and 01 combinations are reserved for future use.) The OFFSET field specifies an offset from the start of the message (i.e., the first octet of the ID field in the domain header). A zero offset specifies the first byte of the ID field, etc.

ラベル長部の先頭2ビットは別の意味を持ち、00の場合は1オクテットでラベル長を示すが、11の場合は次のオクテットと合わせて16ビットの情報とし、ドメイン名のデータ量を圧縮（メッセージ圧縮）することに用いられる。

01 の場合を EDNS0 で定義している。

1.3. OPT Pseudo-RR

  • Additional section に付加される

6.1.1. Basic Elements

An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the additional data section of a request.

  • OPT レコードを含めた応答 リクエストに OPT が含まれている場合、応答にも OPT を含めなければならない。

6.1.1. Basic Elements

If an OPT record is present in a received request, compliant responders MUST include an OPT record in their respective responses.

  • キャッシュしてはならない キャッシュ、フォワード、保持、読み込みなどはしてはならない。

6.1.1. Basic Elements

OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from master files.

  • 期待される応答

複数の OPT を持つクエリを受け取った場合は 'FORMERR' を返さないといけない。

If a query message with more than one OPT RR is received, a FORMERR (RCODE=1) MUST be returned.

実装されていないバージョンのリクエストを受け取った場合は 'BADVERS' を返さないといけない。

If a responder does not implement the VERSION level of the request, then it MUST respond with RCODE=BADVERS.

BADVERS は、拡張 RCODE には 16 が設定される。

This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS RCODES registry.

1.3.1. リソースレコードフォーマット

TTL のパートで拡張 RCODE やフラグが設定される。

クライアント側での有効化

検証は dig +edns=0 ... で良いが、 resolv.conf の option として有効化することができる。

http://man7.org/linux/man-pages/man5/resolv.conf.5.html

edns0 (since glibc 2.6) Sets RES_USE_EDNSO in _res.options. This enables support for the DNS extensions described in RFC 2671.

PreviousZone TransferNextENDS Options in dig

Last updated