EDNS协议报文(RFC2671)

 

EDNS协议报文(RFC2671)

一、伪资源记录
  1. 一个伪资源记录可以加入到请求或应答报文的附加资源记录字段中，之所以叫做伪记录是因为它属于传输层的消息，而不是关于DNS的，伪资源记录不能被缓存，转发，存储或者从主文件中加载，一个dns报文中要么就不要有，要么有一个伪资源记录，不能多余1个。
  2. 伪资源记录包含固定部分和使用{attribute, value}对表示的可变的选项信息。固定部分包含一些DNS的元信息还有一小部分我们不想放在{attribute, value}对中的协议元素。
  3. 伪资源记录的固定部分格式如下：
     Field Name   Field Type     Description
     ------------------------------------------------------
     NAME         domain name    empty (root domain)
     TYPE         u_int16_t      OPT
     CLASS        u_int16_t      发送者的UDP载荷大小(sender's UDP payload size)
     TTL          u_int32_t      扩展的RCODE和flags(extended RCODE and flags)
     RDLEN        u_int16_t      describes RDATA
     RDATA        octet stream   {attribute,value} pairs
  4. 伪资源记录中的可变部分编码在RDATA中，并且要么是0，要么是下面的格式：
                +0 (MSB)                            +1 (LSB)
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  0: |                          OPTION-CODE                          |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  2: |                         OPTION-LENGTH                         |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  4: |                                                               |
     /                          OPTION-DATA                          /
     /                                                               /
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   OPTION-CODE    (Assigned by IANA.)
   OPTION-LENGTH  Size (in octets) of OPTION-DATA.
   OPTION-DATA    Varies per OPTION-CODE.

  5. 发送者的UDP载荷大小是发送者可以接收的最大的UDP载荷大小，注意路径的MTU可能会比这个值小。
    5.1. 注意512的UDP载荷需要576的IP报文缓存，载以太网选择1280的大小是比较明智的，选择太大的值可能会受到中间网关的ICMP信息，或者就直接把数据包丢弃了。
    5.2. 建议发送者和响应者在考虑报文大小的时候，都是用MTU
    5.3. 请求者的最大载荷可能会改变，所以在另外一端不能缓存这个结果。
    5.4. The responder's maximum payload size can change over time, but
       can be reasonably expected to remain constant between two
       sequential transactions; for example, a meaningless QUERY to
       discover a responder's maximum UDP payload size, followed
       immediately by an UPDATE which takes advantage of this size.
       (This is considered preferrable to the outright use of TCP for
       oversized requests, if there is any reason to suspect that the
       responder implements EDNS, and if a request will not fit in the
       default 512 payload size limit.)

    5.5. Due to transaction overhead, it is unwise to advertise an
       architectural limit as a maximum UDP payload size.  Just because
       your stack can reassemble 64KB datagrams, don't assume that you
       want to spend more than about 4KB of state memory per ongoing
       transaction.