feat: add test/.test to server.allowedHosts/server.cors.origin by default
#19250
Conversation
| // allow test and .test by default as they will never be registered | ||
| // https://datatracker.ietf.org/doc/html/rfc6761#section-6.2 | ||
| if (hostname === 'test' || hostname.endsWith('.test')) { | ||
| return true | ||
| } |
There was a problem hiding this comment.
For the test domain name / hostname, the document mentions:
- Application software SHOULD NOT recognize test names as special,
and SHOULD use test names as they would other domain names.
Should we not handle the test hostname in that case?
For TLDs I think it's fine since it doesn't mention anything like that https://datatracker.ietf.org/doc/rfc2606/
There was a problem hiding this comment.
I think that sentence is meant to include both test and *.tests. So I think we should include both test / *.test or not include both.
The domain "test.", and any names falling within ".test.", are special in the following ways:
(FYI the last dot of test./.test. is to clarify that it's the last item)
There was a problem hiding this comment.
Maybe we should not add .test anyway as trusting the (cache) DNS server does not necessarily mean you can trust the IPs listed in that DNS server.
There was a problem hiding this comment.
I see. Then I guess technically it discourages treating test TLDs differently, so I think I'm somewhat leaning on not adding .test as a special case 🤔
There was a problem hiding this comment.
Maybe we should not add
.testanyway as trusting the (cache) DNS server does not necessarily mean you can trust the IPs listed in that DNS server.
I don't quite understand this reasoning. You would never hit a public (potentially malicious) site under the .test TLD, so a remote attacker could never change DNS resolving of such a domain. Do you mean there is no built-in security on any modern system that prevents local DNS cache from containing (injected) .test domains? (don't know, thought the system would be responsible of ensuring this)
There was a problem hiding this comment.
Let's say there's an internal DNS server and you and your team all uses that DNS server. Then, a member of your team added foo.test that points to some IP. You know that the DNS server would not fool you, but don't know whether the IP foo.test is pointing is trustable. In most cases, you would never add a DNS record that points to an IP that you don't hold, but you can point to an IP you don't have control of.
You may say that you should never put an IP you don't control, but it's not enforced by something, and there maybe a user that is using .test like that.
There was a problem hiding this comment.
Let's say there's an internal DNS server and you and your team all uses that DNS server. Then, a member of your team added
foo.testthat points to some IP. (...)
Thanks for explanation. I just thought there would be system level safeguards that would prevent any modern system from ever resolving the .test domain via DNS. But I am probably asking for too much here and we cannot count on such (potential) system level implementations, and anyway that would be against the rfc6761 Application software SHOULD NOT recognize test names as special principle.
Co-authored-by: patak <[email protected]>
|
Closing for now as it seems it's not something everyone would expect. |
|
Appreciate you considering this one. |
Description
Built on top of #19249