xdns2.0

[LjhAUMEM]

一些想法，防止以后忘记

protocol

• 取 client id/padding bytes 高 1bit 分片位，低 2bit 记录位
• a aaaa cname 同 response 里的 answer 开头两个字节的 i/n 改为 i == 0 时候才有 n，其余单 i

todo

• frag
• cname
• optional edns0

总感觉忘了什么，先写这些 (年纪老老就这么健忘了，哎)

[LjhAUMEM]

2.0 预计改动

1. 支持配置 域名label最大长度 域名最大长度
2. 支持配置 initPollDelay maxPollDelay pollDelayMultiplier (仅客户端) maxResponseDelay (仅服务端)
3. 支持配置 ends0 (仅长度字段，对于服务端意义为 mtu，对于单个查询将先预测 cap，再决定是否 frag，上层无需再限制 mtu)
4. 删除 sendLoop
5. 添加 SocketConfig 配置 (用于改回多 socket 模式)，同时将只支持作为最后一层配置

[LjhAUMEM]

原来 make chan 的容量不是 1，是 0，我说为什么卡住了，学到了

[LjhAUMEM]

终于进入测试阶段，虽然不要求上层配置 mtu 了但也不是无脑可用，需要搭配 extraPoll minAvailable，得想想怎么解释这两

[LjhAUMEM]

server

Details

{
  "log": { "loglevel": "debug" },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 53,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "5783a3e7-e373-51cd-8642-c83782b807c5"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "mkcp",
        "kcpSettings": {
          "tti": 200
        },
        "finalmask": {
          "udp": [
            {
              "type": "xdns",
              "settings": {
                "domains": [
                  {
                    "name": "t.example.com",
                    "types": [1, 5, 16, 28],
                    "edns0": 0
                  }
                ],
                "minAvailable": 3
              }
            }
          ]
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom"
    }
  ]
}

client

Details

{
  "log": { "loglevel": "debug" },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 1080,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "address": "127.0.0.1",
        "port": 53,
        "id": "5783a3e7-e373-51cd-8642-c83782b807c5",
        "encryption": "none"
      },
      "streamSettings": {
        "network": "kcp",
        "kcpSettings": {
          "tti": 200
        },
        "finalmask": {
          "udp": [
            {
              "type": "xdns",
              "settings": {
                "domains": [
                  {
                    "name": "t.example.com",
                    "lenLimit": 200,
                    "labelLimit": 1,
                    "types": [
                      1,
                      5,
                      16,
                      28
                    ],
                    "edns0": 1232
                  }
                ],
                "resolvers": [
                  {
                    "type": "udp",
                    "settings": {
                      "addr": "127.0.0.1:53"
                    }
                  }
                ],
                "extraPoll": 1
              }
            }
          ]
        }
      }
    }
  ]
}

[RPRX]

@LjhAUMEM rebase，ready 时说一声

[LjhAUMEM]

@LjhAUMEM rebase，ready 时说一声

在测 quic，今天或明天

quic transport 单独拿出来用依赖 SetReadDeadline close 啊，如果没有实现就会无限阻塞，需要把 pkt close 和 tr close 顺序对换下

https://github.com/quic-go/quic-go/blob/3c2c36b259ce06fd8cc14458cc8b0c8f408462fd/transport.go#L467-L477

[LjhAUMEM]

果然不回空响应是不行的，中转直接就罢工了，明天需要小改一下 respManager

[LjhAUMEM]

现在客/服端开 debug 可看到 resolver 的 edns0


有意思的是 8.8.8.8 谷歌才 512

[LjhAUMEM]

遇到点问题，需要重头排查，时间不确定，我先把文档弄了

[LjhAUMEM]

quic 怎么弄都不行，依旧只能 kcp，这样看来弄掉 mtu 似乎又没必要了

[LjhAUMEM]

还是太想一步达到完美了，quic 的支持以后再说吧，虽然还有一个方法没有验证

时间拖的太久了，先把 #6692 解决了，然后其他的分片仅给保留客户端保留，毕竟查询越多下行越快，加回 sendLoop，服务端还是老模式，也只有服务端需要配置 mtu