FQDNs handled incorrectly
Posted: Mon Sep 03, 2018 3:40 pm
DNS standards say that proper FQDNs end in a dot (.) to signify the root zone.
Other names like foo.bar might or might not be evaluated relative to the local machine's search domain, depending on local configuration. They might give unexpected results after new TLDs like .box or .cloud get delegated by ICANN. This is why I try to use a trailing dot everywhere (even if others usually dont).
However, accessing pages like https://www.google.com./ with NoScript active, only offers to block or allow the "com." domain.
This would pretty much defeat the purpose of NoScript.
IMHO, https://www.google.com./ should be handled the same as https://www.google.com/
Might need careful testing if relative internal domains would be negatively affected by such a change.
Other names like foo.bar might or might not be evaluated relative to the local machine's search domain, depending on local configuration. They might give unexpected results after new TLDs like .box or .cloud get delegated by ICANN. This is why I try to use a trailing dot everywhere (even if others usually dont).
However, accessing pages like https://www.google.com./ with NoScript active, only offers to block or allow the "com." domain.
This would pretty much defeat the purpose of NoScript.
IMHO, https://www.google.com./ should be handled the same as https://www.google.com/
Might need careful testing if relative internal domains would be negatively affected by such a change.