http://www.stackoverflow.com./ does not work, notice trailing dot.

Bad Request - Invalid Hostname 
HTTP Error 400. The request hostname is invalid.

Should servers be configured to deny any URLs without a trailing dot? (Without the trailing dot they are not FQDNs, per RFCs, they are relative domain names.)

Could not a rogue DHCP server could push a dns suffix search path to clients and exploit this?
Assuming a rogue DHCP server was able to push the dns search suffix of "evildomain.com", a user going to chase.com, would then result in going to "chase.com.evildomain.com." A user going to "chase.com." (with trailing dot, its a FQDN) would not be vulnerable to this exploit.

Just about every URL I see published in the media is relative (as the trailing dot is not explicit, and only becomes a true FQDN once trailing dot is added by the underlying libraries).

Should we not enforce absolute domain names, or FQDNs, as much as possible?

On Windows, could not a malicious webserver simply change an end user's dns suffix search path? on *nix boxes, privilege escalation would be needed to update resolv.conf (where dns search suffixes are configured), but would nix users not still be vulnerable to a DHCP spoofing scenario?

  • FYI: This is more of a webserver question than a DNS question. From a DNS perspective the dotted and non-dotted versions are 100% equivalent. The difference is the HTTP host header that the browser transmits and how the server handles the request.
    – Andrew B
    Apr 15, 2015 at 21:23
  • @AndrewB without the trailing dot, a dns name is not fully qualified, per RFC 1738,... therefore, a dotted and non-dotted versions are not equivalent
    – nandoP
    Apr 15, 2015 at 21:29
  • Yes, I know of the RFCs. I'm speaking from a functional perspective. Presence of the dot in this scenario does not change the A record that is returned. My point was that this question was tagged with DNS, but the difference in behavior that you're observing in the example is not due to DNS.
    – Andrew B
    Apr 15, 2015 at 21:33
  • 1
    There are two things going on here. 1) Which server you get based on your query/queries. 2) How that server will react.
    – 84104
    Apr 15, 2015 at 21:34

3 Answers 3


Yes, this is a vulnerability. No, servers should not stop offering content when queried using internet relative domain names.

Trying to figure out if a name is internet relative or just relative is not a problem with a good stateless general solution. A bad stateless solution is to abolish the use of all relative naming. Relative names exist for valid reasons.

Care should be taken to ensure that the using FQDN results in the same content as the internet relative domain name. This is mostly an issue for http servers.

If you want to be zealous without being obnoxious:

  • never use internet relative domain names when you can use FQDN
  • use permanent redirects 308 or 301 on your webservers to point clients in the right direction.

Whenever I configure anything that accepts a DNS domain name, I include the trailing dot. Some systems reject this in their attempts to validate the input, which is a shame. Windows clients that rely on DNS devolution for AD-walking can be troublesome, if you have a two-part domain suffix. MS have documented workarounds.

Reference resolv.conf... The equivalent Windows configuration also requires privilege elevation to effect a change.


By default DNS clients try queries containing at least one dot as FQDN first before trying the search path.

  • looks like not all dns clients can be trusted to do this homepage.ntlworld.com/jonathan.deboynepollard/FGA/…
    – nandoP
    Apr 15, 2015 at 19:48
  • couldn't a malicious webserver subvert this default dns client behavior on a windows box by leveraging ActiveX or similar? (1. change dns client default behavior 2. add malicious dns search suffix)?
    – nandoP
    Apr 15, 2015 at 19:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.