Onderwerp: 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. =20

For example, these two URLs both go to the CNN Web site in Internet
Explorer:

http://www.cnn.com/
http://www.cnn.com./

However, Internet Explorer considers these two domain names to be =
different
when it comes to cookies. "cnn.com." gets a different cookie from =
"cnn.com"
This behavior of Internet Explorer is a bug, but probably not a =
particularly
bad one.

Here's another example at Internic which treats the query "com" =
different
than "com.".

http://reports.internic.net/cgi/whoi...&type=3Ddomain
http://reports.internic.net/cgi/whoi...&type=3Ddomain

My two questions: How much other software behaves incorrectly because =
of a
trailing period on a domain name? Do any of these problems represent
serious bugs?

Richard M. Smith
http://www.ComputerBytesMan.com

Richard M. Smith wrote:

> 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.
>
> ...
>
> However, Internet Explorer considers these two domain names to be different

Is it IE or is it the Windows resolver?

> From: Richard M. Smith [mailtoms@computerbytesman.com]
> Sent: Monday, October 13, 2003 5:18 PM
> To: BUGTRAQ@SECURITYFOCUS. 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 d

<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

+---------- On Oct 14, Michael Wojcik said:
| As I read the grammar given by RFC 1034 (Domain Names) in 3.5,

The grammar specifies only the "preferred name syntax". Section 3.1
clearly allows dot-terminated names:

When a user needs to type a domain name, the length of each label is
omitted and the labels are separated by dots ("."). Since a complete
domain name ends with the root label, this leads to a printed form which
ends in a dot. We use this property to distinguish between:

- a character string which represents a complete domain name
(often called "absolute"). For example, "poneria.ISI.EDU."

When you tell your web browser to go to "http://cnn.com", this will not
necessarily take you to the same target IP as "http://cnn.com.", if
there is some other 'cnn.com' in your DNS search path.

(Suppose your DNS search path is set to 'local.example.com myisp.com';
If the resolver wanted to look up 'cnn.com', it would try
'cnn.com.local.example.com' and 'cnn.com.myisp.com', and if neither of
those resolved, it would use 'cnn.com'. A trailing period at the end of
the FQDN tells the resolver that you do not want the DNS search
path to be used.)

For this reason, it may not be a good idea for the browser to attempt to
simplify 'cnn.com.' to 'cnn.com'. If it did, an internal 'cnn.com'
(cnn.com.myisp.com) might be able to access cookies belonging to
'cnn.com.', and vis versa.

It is also worth noting that the user may be going through caches or
proxies, possibly transparent to them, and so regardless of what
'cnn.com' resolves to locally, it may resolve to something different for
the thing that makes the final HTTP connection. So, even if locally it
appears that 'cnn.com' and 'cnn.com.' both resolve to the same IP(s),
that does not mean that your HTTP request will actually end up going
to those IPs.

(This means you can't use that as a method to decide whether or not, for the
purpose of your HTTP requests, 'cnn.com' == 'cnn.com.')

On Tue, Oct 14, 2003 at 10:13:26AM -0700, Michael Sierchio wrote:
> Richard M. Smith wrote:
>
> >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.
> >
> >...
> >
> >However, Internet Explorer considers these two domain names to be different
>
> Is it IE or is it the Windows resolver?