At 12:01 -0300 5/19/05, MARLON BORBA wrote:

Hmm, they've always teached to me that . (dot) at the end of hostnames indicates the (hidden) Root domain:

blah.domain.com.[Root]

And my teachers always said that we don't need to write the final . because every domain belongs to the Root domain.

This thread needs to consider the layering of applications. E.g., Applications: Mail, Web, things using gethostbyname (host names, etc.) -------------------------------------------------------- Infrastructure: DNS, etc, (such as X.500) (domain names) Apps deal with host names, DNS deals with domain names. To the DNS, host names are a subset of domain names. To applications, domain names per DNS are "behind that interface." Apps deal with host names and other names, all of which, if running over DNS, are mapped into domain names. Referring to the above text, yes, a full qualified domain name ends in a "dot." Whenever talking to or among DNS elements, the "dot" terminates the FQDN. It must syntactically - a zero length label is the "null termination" of the domain name. Applications passing domain names to the DNS (not strings of domain names) must have this terminating null. However, this does not mean that the applications have to make the user or GUI require the null, as that interface is likely to be dealing with a string version of the name. Some DNS applications, such as dig, don't require a dot at the end of the name - if one is missing, the dot is appended. The user is alleviated of the burden of adding the dot - but on the other hand - the dot is forced upon the user. Some applications, being agnostic, won't add anything to the user's input. (This is true for non-DNS applications too.) This gives the knowledgeable user more power - unique things can be done. But it means that novices have more to learn. Some applications assume the user is lazy and adds the dot in all instances. Knowledgeable users get burned because now here are two terminating dots at times - until these users remember to "fall back" to not terminating domain names. I've seen all three kinds of applications. The latter ones tend to be the quick and dirty prototypes that don't see the light of day. The moral is that applications are choosing when to add the terminating dot. It's always there in DNS, but people don't access the DNS without going through an application. As far as whether an "_" is "legal" in a host name, you can attack the question in many ways. When cast into a domain name, "_" is legal. DNS assigns no special meaning to that character in domain names. Not even in the SRV record - if one reads the document carefully, there is no special meaning assigned by DNS, only a convention proffered that uses the "_". The convention is a function of the applications using the SRV, not the manipulation of the SRV within the DNS. When cast into a host name, "_" is not among the legal characters specified in the ancient documents. But documents are just documents - arguing over what's legal according to them is about as useful as watching haircuts. (Unless you are on a software design & implementation team.) When thrown into applications, "_" may or may not have a special meaning. Some applications will raise exception to "_". The more interesting question is why? Is this simply because of the ancient documents' restrictions? Is there some parsing consideration? Is there a special semantic inferred? It really isn't important whether the character is "legal" or not (until there is a network police force). What is more important is whether the character will work in all environments in which the name is needed. Will the "_" work in DNS domain names? Yes, unless there is a but in the DNS implementation (always a caveat). Will the "_" work in a host name? Only if the applications in use, referring to the host, can handle such a name. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.