Dokodemo-door with V2Ray DNS Changes DNS TTL

[ghost]

What version of V2Ray are you using?

V2Ray 4.44.0 (V2Fly, a community-driven edition of V2Ray.) Custom (go1.17.5 linux/amd64) A unified platform for anti-censorship.

What's your scenario of using V2Ray?

Just use V2Ray as DNS shunts.

What problems have you encountered?

Inbound dokodemo-door changes TTL of DNS record to 600 seconds, whatever the original TTL is, though I already disabled the cache of V2Ray internal DNS.

What's your expectation?

Dokodemo-door keeps the record unchanged.

Please attach your configuration here

Server configuration:

The issue does not relate to servers, so omitted.

Client configuration:

{
  "dns": {
    "hosts": {
      "geosite:category-ads-all": "0.0.0.0"
    },
    "servers": [
      {
        "address": "127.0.0.1",
        "port": {{ port for overseas dns query, listened by local coredns }}
      },
      {
        "address": "127.0.0.1",
        "port": {{ port for home dns query, listened by local coredns }},
        "domains": ["geosite:geolocation-cn"]
      }
    ],
    "queryStrategy": "UseIPv4",
    "disableFallback": true,
    "disableCache": true
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 53,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "127.0.0.1",
        "port": {{ port for overseas dns query, listened by local coredns }},
        "network": "tcp,udp",
        "timeout": 0
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "dns"
    }
  ]
}

Server log:

The issue does not relate to servers, so omitted.

Client log:

I just set loglevel to debug and redirect its output here.

2022/01/08 15:08:36 [Info] app/dns: DNS: created UDP client initialized for 127.0.0.1:{{ port for overseas dns query, listened by local coredns }}
2022/01/08 15:08:36 [Info] app/dns: DNS: created UDP client initialized for 127.0.0.1:{{ port for home dns query, listened by local coredns }}
2022/01/08 15:08:36 [Debug] app/proxyman/inbound: creating stream worker on 127.0.0.1:53
2022/01/08 15:08:36 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:53
2022/01/08 15:08:36 [Info] transport/internet/udp: listening UDP on 127.0.0.1:53
2022/01/08 15:08:36 [Warning] V2Ray 4.44.0 started
2022/01/08 15:08:44 [Debug] [116576051] proxy/dokodemo: processing connection from: 127.0.0.1:52887
2022/01/08 15:08:44 [Info] [116576051] proxy/dokodemo: received request for 127.0.0.1:52887
2022/01/08 15:08:44 [Info] [116576051] app/dispatcher: default route for udp:127.0.0.1:{{ port for overseas dns query, listened by local coredns }}
2022/01/08 15:08:44 [Info] [116576051] proxy/dns: handling DNS traffic to udp:127.0.0.1:{{ port for overseas dns query, listened by local coredns }}
2022/01/08 15:08:44 127.0.0.1:52887 accepted udp:127.0.0.1:{{ port for overseas dns query, listened by local coredns }}
2022/01/08 15:08:44 [Debug] app/dns: domain google.com will use the first DNS: [UDP:127.0.0.1:{{ port for overseas dns query, listened by local coredns }}]
2022/01/08 15:08:44 [Debug] app/dns: DNS cache is disabled. Querying IP for google.com at UDP:127.0.0.1:{{ port for overseas dns query, listened by local coredns }}
2022/01/08 15:08:44 [Debug] app/dns: UDP:127.0.0.1:{{ port for overseas dns query, listened by local coredns }} querying DNS for: google.com.
2022/01/08 15:08:44 [Debug] transport/internet/udp: dispatch request to: udp:127.0.0.1:{{ port for overseas dns query, listened by local coredns }}
2022/01/08 15:08:44 [Info] transport/internet/udp: establishing new connection for udp:127.0.0.1:{{ port for overseas dns query, listened by local coredns }}
2022/01/08 15:08:44 [Info] app/dispatcher: default route for udp:127.0.0.1:{{ port for overseas dns query, listened by local coredns }}
2022/01/08 15:08:44 [Info] proxy/dns: handling DNS traffic to udp:127.0.0.1:{{ port for overseas dns query, listened by local coredns }}
2022/01/08 15:08:44 [Info] app/dns: UDP:127.0.0.1:{{ port for overseas dns query, listened by local coredns }} got answer: google.com. TypeA -> [172.217.14.206] xxx.xxxxxxms
2022/01/08 15:08:44 [Debug] app/dns: UDP:127.0.0.1:{{ port for overseas dns query, listened by local coredns }} updating IP records for domain:google.com.
2022/01/08 15:08:52 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/dns: connection ends > context canceled
2022/01/08 15:08:52 [Info] transport/internet/udp: failed to handle UDP input > io: read/write on closed pipe

Other configurations (such as Nginx) and logs here

coredns config (Corefile):

.:{{ port for overseas dns query, listened by local coredns }} {
  bind 127.0.0.1
  forward . tls://xxx.xxx.xxx.xxx:xxxx {
    max_fails 0
    tls_servername aaa.aaa
  }
}
.:{{ port for home dns query, listened by local coredns }} {
  bind 127.0.0.1
  forward . tls://yyy.yyy.yyy.yyy:yyyy {
    max_fails 0
    tls_servername bbb.bbb
  }
}

dig google.com output (first time):

; <<>> DiG 9.16.23 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26744
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		600	IN	A	172.217.14.206

;; Query time: xxx msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: {{ date and time }}
;; MSG SIZE  rcvd: 44

Note: the Query time is larger than 100 ms.

dig google.com output (second and other times):

; <<>> DiG 9.16.23 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 676
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		600	IN	A	172.217.14.206

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: {{ date and time }}
;; MSG SIZE  rcvd: 44

Note that the query time (3 ms) is so short that the query must be finished in local machine. I used wireshark and found that the DNS query was finished just in port 53. It did not even enter coredns port! So the problem should be with dokodemo-door.

[ghost]

BTW, when I run dig google.com -p{{ port for overseas dns query, listened by local coredns }} (which directly queries DNS via coredns, bypassing V2Ray), the issue does not happen.

[database64128]

What you observed is V2Ray's internal DNS server limiting TTL to be no higher than 600. #1179 was made to fix this bug, but was rejected by @xiaokangwang. You can apply this patch yourself, or use downstream forks like Shadowsocks-NET/v2ray-go.

[ghost]

Thank you! Since this is really a bug and not fixed (or intentionally not to fix), should I close the issue or just let it alone?

[database64128]

I think we can keep it open for more discussions.

[ghost]

Wait, the issue still exists in the Shadowsocks-NET/v2ray-go repo. I use the latest release from Actions (this one). The phenomenon is the same.

[ghost]

I just tried to find the reason. Since I know little about golang, I just globally searched 600 and found its two occurence. And I forked v2ray-go and changed these 600 to 432 and 543 seperately. Then I use Actions to build and found that the TTL is now 432. So the reason should be here.

[database64128]

The lookup method currently only returns a slice of IPs. We need to add new methods that return DNS RRs.

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days

[4-FLOSS-Free-Libre-Open-Source-Software]

Overriding any DNS reply TTL to 600 still an issue in V2Ray 5.13.0

[4-FLOSS-Free-Libre-Open-Source-Software]

I have identified an issue related to the handling of DNS TTL (Time to Live) values in V2ray. I would like to request a feature enhancement that addresses this issue and provides more flexibility in the TTL manipulation process. Currently, when V2ray encounters DNS responses with TTL values shorter than 600 seconds, it artificially expands the TTL to a fixed value of 600 seconds. This behavior becomes problematic in situations where shorter TTLs are explicitly set by authoritative DNS servers, such as the case of the domain "dns.msftncsi.com" used for Microsoft OS testing, where a TTL of 30 seconds is intended.

I kindly request that you address the forced override of DNS TTL values to 600 seconds in V2ray. Instead, I propose implementing a more flexible approach that allows for the preservation of the original TTL as specified by the authoritative DNS server.

TTL Preservation: Modify the DNS resolver module in V2ray to retain the original TTL value received from the authoritative DNS server, regardless of its duration. This modification will ensure that V2ray accurately respects the TTL settings dictated by the DNS infrastructure.

Or

Fine-grained Configuration: Introduce a configuration parameter that provides users with the ability to define their desired behavior for handling short TTL values. This parameter should allow users to choose between preserving the original TTL, overriding it with a custom value, or using the default behavior of V2ray (expanding to 600 seconds).

By implementing these changes, V2ray will become more adaptable to various DNS environments and requirements. Users will be able to maintain the integrity of the TTL values and ensure accurate DNS resolution without forced overrides.

• #1179