>
>
> --On Friday, 28 September, 2007 09:48 +1000 Mark Andrews
> <Mark_Andrews@xxxxxxx> wrote:
>
> >...
> >> It's not. Even without IPv6, having search domains means you
> >> can get unexpected results. If that's not acceptable, don't
> >> complain, but put a period behind your FQDNs.
> >
> > Please state were in RFC 952 a final period is legal in
> > a hostname.
> >
> > Remember applications take HOSTNAMES not DOMAIN NAMES.
> > There are HOSTNAMES that you cannot store in the DNS.
> > There are DOMAIN NAMES that are not legal HOSTNAMES.
>
> Mark, your recollection and understanding of history and
> vocabulary may be different from mine (and probably is), but I
> think you are getting confused by some informal terminology and
> risking confusing others even further.
>
> RFC 952 in fact prohibits trailing periods in domain names used
> as host names, but 952 is a very early document, superceded by
> all sorts of things both formally and informally. I note, for
> example, that it has been a rather long time since every
> boundary router on the network (a "gateway") had a name ending
> in "-GW" or "-GATEWAY". Please don't read sentences of 952 out
> of context and consider them binding.
>
> You will not find the "hostname" versus "domain" distinction
> made in RFC 1034.
Actually will find the distinction made.
Please go re-read RFC 1034 and RFC 1035.
Mark
3.5. Preferred name syntax
The DNS specifications attempt to be as general as possible in the rules
for constructing domain names. The idea is that the name of any
existing object can be expressed as a domain name with minimal changes.
However, when assigning a domain name for an object, the prudent user
will select a name which satisfies both the rules of the domain system
and any existing rules for the object, whether these rules are published
or implied by existing programs.
For example, when naming a mail domain, the user should satisfy both the
rules of this memo and those in RFC-822. When creating a new host name,
the old rules for HOSTS.TXT should be followed. This avoids problems
when old software is converted to use domain names.
Note: NS specifies a HOST.
3.3.11. NS RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NSDNAME A <domain-name> which specifies a host which should be
authoritative for the specified class and domain.
Note: CNAME is a general DOMAIN.
3.3.1. CNAME RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CNAME A <domain-name> which specifies the canonical or primary
name for the owner. The owner name is an alias.
> 1034 and its conceptual predecessors
> discusses the domain name system as a replacement for the
> hostname one and even notes (correctly) that different
> applications have different syntax rules for names for hosts.
> To make the ambiguity worse, when the term "host" or "hostname"
> is used in applications in conjunction with the DNS, that term
> often refers to the leaf-note label and not to the FQDN. See,
> for example, section 3.7 of RFC 821, which describes
> "Fred.Cambridge.UK" as a possible "host-and-domain identifier".
> However, the familiar "mailbox" is defined as
> <mailbox> ::= <local-part> "@" <domain>
> Note that it is not
> <local-part> "@" <hostname>
> or
> <local-part> "@" <host-and-domain>
>
> RFC 1034 also seems to believe that all fully-qualified (aka
> "absolute") domains names, including those used to refer to
> hosts, end in a period, even if that period is typographically
> omitted for convenience.
> Of course, it also contains a
> masterwork of apparently-circular definition: "A domain is
> identified by a domain name, and consists of that part of the
> domain name space that is at or below the domain name which
> specifies the domain."
>
> While 1034 suggests that the trailing period is always
> permitted, even if it is implied, Section 2.3.1 of 1035 gives a
> syntax that doesn't permit them. But it does so without trying
> to distinguish between a "host" and a "domain". In particular,
> it says that [all of] "The labels must follow the rules for
> ARPANET host names", which is ultimately a reference to 952
> although 1035 repeats the rule. That rule is applied to all
> labels, not just the leaf one or ones identifying hosts.
>
> As an indirect illustration of this, note that 1035 Section 3.5
> describes IN-ADDR.ARPA as supporting "host address to host name
> mapping". That mapping is to an FQDN, not a label or "hostname"
> as you use the term above.
It does for almost all possible hostnames. Maximum length
hostnames can't fit into the DNS. For that mapping to be
valid the data encoded in the FQDN must map back to a valid
hostname.
If I put "!@#@#$%%^&^&*$%^.example.net" in that
PTR record would you claim that it is a valid hostname?
The DNS is much more than a distributed HOST <-> ADDRESS
mapping mechinism. It was designed to be general. This
was a good thing. However that does mean that you need to
be aware of what is valid and what is invalid as the DNS
itself does protect you when you get it wrong.
> RFC 1123 makes explicit provision for trailing dots in
> application interfaces to domain names ("hosts") while noting
> that RFC 822 (and 821) do not permit that syntax in the
> protocols. Nothing has ever permitted a UI designer, even for a
> mail-related program, from accepting the trailing dot as long as
> it is removed (and any searching or aliases resolved) before the
> name goes out on the wire.
But forcing people to put the period in when we have stuffed
up the API is just stupid. RFC 1535 also shows that RFC 1123
was wrong in this respect. An absolute name should always
match without having to remember to put periods at the end.
The common search strategy didn't do this along with
automatically created search lists lead to the *.EDU.COM
fiasco.
The search strategy was modified as reaction to RFC 1535.
It however need to be modified further. I've been arguing
this for years. Getting others to see the issue has been
a problem.
Remember when RFC 1123 and RFC 1535 were written the search
strategy was to try the entered name last. That also ment
you often needed to skip across wildcard MX records so the
search didn't stop on a NODATA response.
If we had though to stop on NODATA as well as trying the
name as entered first when it had multiple labels than I
suspect there wouldn't be a issue now. However the changes
in response to RFC 1535 didn't do that and we need a RFC
that describes how to do searching correctly.
> So I believe the distinction you are trying to make is not
> historically supported, not particularly helpful, ambiguous, and
> probably just plain wrong.
>
>
> regards,
> john
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf