Add Dns Proxy Response TTL Control

[xiaokangwang]

This pull request adds 2 new options for dns proxy protocol.

It allows the adjustment of ttl for dns message output with configuration.

  bool override_response_ttl = 4;
  uint32 response_ttl = 3;

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

This option would be useful to be able to specify the “FakeDNS” answer's expiration TTL.

For real DNS records TTL there are domains with low as 30 seconds. Which was currently expanded to 20x of its specified TTL.
For example, dynamic DNS domains or dns.msftncsi.com.

This TTL Control fixes:

• Decrease FakeDNS TTL #3043
• Dokodemo-door with V2Ray DNS Changes DNS TTL #1528
• fix: dnscommon cache expired within ttl preferred #1179

The other current behavior with the DNS protocol is, that if you once request a domain such as v2fly.org which is TTL 300, If you will request it within the 300 seconds, again, v2fly will always answer with the same static TTL value (600) again. In depended on if the cached value was about to expire within the same time.

This means, the current default TTL of 600 is always 10 minutes in time, independent of v2fly DNS cache is about to expire it record. The TTL value ins answers never decreases. But this would be another issue.

With the new option, one could set a sane lower TTL value at least.

[xiaokangwang]

It is not possible to reply with different TTL for dns request originated from different servers, as the current design does not the dns user to know the origin of the reply. I think the option to reply with a lower ttl should be a low hanging fruit for us.

[dyhkwong]

Even if the TTL value is "fake", it should be a decreasing value but not a fixed value. Why add yet another bad behavior on top of the current bad behavior? IMO this new option is a only dirty hack for #1528 only, and if something like #1179 is refused to be merged, there will be no chance to realize #1528 (comment).

[xiaokangwang]

Even if the TTL value is "fake", it should be a decreasing value but not a fixed value. Why add yet another bad behavior on top of the current bad behavior? IMO this new option is a only dirty hack for #1528 only, and if something like #1179 is refused to be merged, there will be no chance to realize #1528 (comment).

The current DNS query interface does not provide TTL information. So there is no way to provide a decreasing TTL. So this is the only thing that can be achieved without making significant change to the dns module.

As for #1179, I am happy to merge it if it provide a configuration option to opt-in into it, instead of regressively changing existing behavior. This is not a refusal, just a simple least regression requirement that need to be fulfilled before it can be merged.

As for #1528 (comment), it would require a even more efforts to make it happen, my current priority is to implement more transports and proxies, so such change is not in immediate roadmap.