lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Oct 2003 10:48:00 -0700
From: Michael Wojcik <Michael.Wojcik@...rofocus.com>
To: "BUGTRAQ@...URITYFOCUS. COM" <BUGTRAQ@...urityfocus.com>
Cc: "Richard M. Smith" <rms@...puterbytesman.com>
Subject: RE: What software breaks because of this DNS feature?


> From: Richard M. Smith [mailto:rms@...puterbytesman.com] 
> Sent: Monday, October 13, 2003 5:18 PM
> To: BUGTRAQ@...URITYFOCUS. COM
> Subject: What software breaks because of this DNS feature?
> 
> 
> Hi,
> 
> According to RFC1034, "cnn.com" and "cnn.com." should be the 
> same domain names.  However, it doesn't appear that programmers always 
> understand that trailing dots can be added to domain names.  

IIS often fails to interpret a trailing dot correctly:

http://www.microsoft.com/
http://www.microsoft.com./

I used to routinely put a trailing dot on FQDNs when I typed in URLs, since
that should in theory skip extra resolver queries using my configured domain
searchlist.  I had to give up the practice years ago because so many sites
fail with trailing-dot FQDNs.

However: RFC 2616 (HTTP/1.1) requires that the Host header be taken
literally from the request URL, and cites RFC 1738 (Uniform Resource
Locators) for URL format.  RFC 1738 (3.1) cites RFC 1034 (3.5) and RFC 1123
(2.1) for FQDN format.

As I read the grammar given by RFC 1034 (Domain Names) in 3.5, it does *not*
permit a trailing dot:

	<domain> ::= <subdomain> | " "
	<subdomain> ::= <label> | <subdomain> "." <label>
	<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

(A "." must be followed by a <label>, and a <label> cannot be empty.)

RFC 1034 (3.5) does not appear to have the force of a requirement, and other
standards could conceivably take precedence, but this does look like an
argument for the defense.  What in RFC 1034 do you believe requires handling
a trailing dot?

RFC 1123 (Host Requirements) defers to RFC 952 (HOSTS.TXT) for host name
syntax, with the exception that the first character is now allowed to be a
digit.  RFC 952 (ASSUMPTIONS 1) states: "The last character must not be a
minus sign or period".

Given all that, I think HTTP servers are not technically broken if they fail
to interpret a trailing-dot FQDN as equivalent to a no-trailing-dot FQDN.  I
don't know if any of the DNS standards require ignoring the trailing dot in
searches, but that's a side issue for other programs that process FQDNs for
other purposes, such as HTTP "virtual host" processing.

I'd like to believe that support for trailing-dot FQDNs is required, but I
don't think that's the case.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ