Re: ascii decoder

[Jefferson Ogata <jogata () NODC NOAA GOV>]

Slawek wrote:
> rfc 1033: "DOMAIN ADMINISTRATORS OPERATIONS GUIDE"
>
> NAMES
> only the following characters are recommended for use in a host name
> (besides the dot separator):
>            "A-Z", "a-z", "0-9", dash and underscore
>
> Anyway if somebody can confirm it's not allowed to use underscore in the
> hostname, I can show it's easy to modify the decoder so it will not be using
> it anymore ;)

For the following discussion, please try to remember that "host names" and
"domain names" are two different things. Host names are sometimes encoded and
transmitted via DNS as domain names, but many other types of entities are also
transmitted via DNS, and these do not have the same restrictions as host names.

RFC 2181 has the following to say about domain names in general:

| 11. Name syntax
|
| Occasionally it is assumed that the Domain Name System serves only
| the purpose of mapping Internet host names to data, and mapping
| Internet addresses to host names.  This is not correct, the DNS is a
| general (if somewhat limited) hierarchical database, and can store
| almost any kind of data, for almost any purpose.
|
| The DNS itself places only one restriction on the particular labels
| that can be used to identify resource records.  That one restriction
| relates to the length of the label and the full name.  The length of
| any one label is limited to between 1 and 63 octets.  A full domain
| name is limited to 255 octets (including the separators).  The zero
| length full name is defined as representing the root of the DNS tree,
| and is typically written and displayed as ".".  Those restrictions
| aside, any binary string whatever can be used as the label of any
| resource record.  Similarly, any binary string can serve as the value
| of any record that includes a domain name as some or all of its value
| (SOA, NS, MX, PTR, CNAME, and any others that may be added).
| Implementations of the DNS protocols must not place any restrictions
| on the labels that can be used.  In particular, DNS servers must not
| refuse to serve a zone because it contains labels that might not be
| acceptable to some DNS client programs.  A DNS server may be
| configurable to issue warnings when loading, or even to refuse to
| load, a primary zone containing labels that might be considered
| questionable, however this should not happen by default.

Meanwhile, RFC 1034, a.k.a. STD 13, says the following about domain names,
while implicitly defining ARPANET host names:

| 3.5. Preferred name syntax
|
| ... The labels must follow the rules for ARPANET host names.  They must
| start with a letter, end with a letter or digit, and have as interior
| characters only letters, digits, and hyphen.  There are also some
| restrictions on the length.  Labels must be 63 characters or less.

Barry Margolin and others have argued that this RFC pre-dates the establishment
of IETF standard wording for "MUST", and in light of the "preferred" in the
section title, this wording should be treated as a guideline. Nevertheless, it
clarifies the interpretation of what is a valid host name as defined earlier in
RFC 952:

| 1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
| to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
| sign (-), and period (.).  Note that periods are only allowed when
| they serve to delimit components of "domain style names". (See
| RFC-921, "Domain Name System Implementation Schedule", for
| background).  No blank or space characters are permitted as part of a
| name. No distinction is made between upper and lower case.  The first
| character must be an alpha character.  The last character must not be
| a minus sign or period....  Single character names
| or nicknames are not allowed....

Remember that RFC 952 pre-dates the standardization of DNS, and was actually a
specification for name format in the SRI-NIC's HOSTS.TXT.

One constraint from RFC 952 was relaxed later in RFC 1123:

| 2.1  Host Names and Numbers
|
| The syntax of a legal Internet host name was specified in RFC-952
| [DNS:4].  One aspect of host name syntax is hereby changed: the
| restriction on the first character is relaxed to allow either a
| letter or a digit.  Host software MUST support this more liberal
| syntax.

This leaves us with the following state of affairs:

1. Internet host names are 2 to 24 characters in length and drawn from
[A-Za-z0-9\-\.]. Apparently this length constraint does not apply any longer,
and is commonly now believed to be relaxed to 63 characters, though I don't
know what RFC explicitly states this.

2. DNS domain names are composed of labels 1 to 63 characters in length having
"any binary string" as their content, and limited to 255 characters total,
including separators. It is not clear to me how one would encode some binary
values in a DNS query, as they would overlap with the label compression
algorithm, but it is clear that DNS itself doesn't restrict the character set
of the namespace in principle.

For the purposes of an exploit encoded in a domain name, certainly an
underscore would work, as long as it is delivered to the program being
exploited. If this is via a DNS name, it needn't necessarily be a host name,
but even so, I hardly think an attacker will be concerned about conforming to
the RFCs. Note that under BIND 8, you may need to add "check-names master
ignore" to the zone definition when defining these names.

--
Jefferson Ogata <jogata () nodc noaa gov> National Oceanographic Data Center
You can't step into the same river twice. -- Herakleitos