blanks in owner and host names

[Bob Vance]

>Well send it back to the manufacture.  Blanks have never
>been legal in a hostname.  If they can't get basics like
>a hostname right what else have they stuffed up.

Well, it's an excellent 802.11b wireless bridge and I'm not about to
send it back -- it works flawlessly for my laptops in my home network
at 11Mbps and I can live with the 'named' complaints in syslog :)

> Blanks have never been legal in a hostname.
What, exactly, does this mean?
Note that 'dhcpd' is *changing* those blanks to \032, so BIND
is never really "seeing" a blank.
I'm sure that it's not just an accident that 'dig' also converts the
blanks in a request to \032 before making its query.

So is this conversion to \032 just a work-around kludge to make sure
that spaces are never really used?  If so, why does 'named' complain
about the *encoded* name, which contains no actual blanks?


-------------------------------------------------
Tks        | <mailto:BVance at sbm.com>
BV         | <mailto:BobVance at alumni.caltech.edu>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430           11455 Lakefield Dr.
Fax 770-623-3429           Duluth, GA 30097-1511
=================================================





-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org]On
Behalf Of Mark.Andrews at nominum.com
Sent: Friday, January 12, 2001 11:35 PM
To: bobvance at alumni.caltech.edu
Cc: bind-users at isc.org
Subject: Re: blanks in owner and host names



>
> Linux RH 6.1 with kernel update to 2.2.16
> dhcp server 3.0b2pl11
> BIND 8.2.3T9B
>
> I have dynamic DNS updates working fine (except for one tiny problem
> with dhcpd that I'm researching, and which problem is really
irrelevant
> to this posting).
> I have a client that has blanks in it's name (and, even if I wanted
to,
> I cannot change it -- it's encoded in firmware.)

	Well send it back to the manufacture.  Blanks have never
	been legal in a hostname.  If they can't get basics like
	a hostname right what else have they stuffed up.

>
> The forward dynamic update gets into the dynamic zone file fine, with
> the blanks encoded as \032 :
>
> ORiNOCO\032RG-1000\03201a393  18000  IN  A   192.168.1.28   ;CL=2
>
>
> I assumed that this was OK, since I figured that blanks might be a
> problem :)

	See RFC 1034/1035 for the presentation form of domainnames.
	Note the presentation form of a domainname may not contain
	white space.

>
> In fact, lookups *are* working fine:
>
> herman# dig  'ORiNOCO RG-1000 01a393.dynamic.vance.'
>    ...
> ;; QUERY SECTION:
> ;;      ORiNOCO\032RG-1000\03201a393.dynamic.vance, type = A, class =
IN
>
> ;; ANSWER SECTION:
> ORiNOCO\032RG-1000\03201a393.dynamic.vance.  5H IN A  192.168.1.47
>    ...
>
>
> 'nslookup' has a little problem with the blank, but it also works if
> I do the encoding for it:
>
> herman# nslookup -d 'ORiNOCO\032RG-1000\03201a393.dynamic.vance.'
>    ...
> QUESTIONS:
>         ORiNOCO\032RG-1000\03201a393.dynamic.vance, type = A, class =
IN
>     ANSWERS:
>     ->  ORiNOCO\032RG-1000\03201a393.dynamic.vance
>         internet address = 192.168.1.47
>    ...
>
>
> So I'm happy as a clam except for two things:
>
> 1) (this is really OT, but I thought I'd mention it for grins
>    )
>    'ping', 'telnet', etc. on Linux doesn't like the blank in the name
> and just return "Unknown host" .
> This appears to be a resolver library issue (original Linux programs),
> since resolver code on both Win95 and HP-UX *do* accept blanks in the
> names and 'ping' works fine against those names.
>
> 2) I happened to be looking in the syslog file while researching the
>    aforementioned dhcpd problem (which is that dhcpd does *not* encode
> correctly the reverse entry and it is, therefore, not entered into the
> zone file correctly), and I saw the following BIND messages:
>
>    ...
> owner name "ha\032ri\032xx.dynamic.vance" IN (primary) is invalid -
> proceeding anyway
> master zone "dynamic.vance" (IN) loaded (serial 2001011121)
> host name "ha\032ri\032xx.dynamic.vance" (owner
> "45.1.168.192.dynamic.in-addr.arpa")
>      IN (primary) is invalid - proceeding anyway
> master zone "dynamic.in-addr.arpa" (IN) loaded (serial 2001011117)
>    ...
> owner name "ORiNOCO\032RG-1000\03201a393.dynamic.vance" IN (primary)
is
> invalid -
>      proceeding anyway
>
>
> The first two come from reloading the dynamic zones which include a
> couple of test
> updates using 'nsupdate'.
>
> The third one comes because of the DHCP dynamic update.
>
> In both cases (manual 'nsupdate' and DHCP dynamic update), the names
> *are* added
> to the zone, as I said above.
>
> So, I guess the questions are:
>
> Why is BIND complaining?

	Because it was configured to.  The default is to reject.

>    (NOTE: both 8.2.2-p5 and 8.2.2-p7 make the same complaint.
>    )
> Should DHCP be encoding the name the way it does?
>    (I'm thinking, "Yes", since 'dig' encodes it the same way for its
> query.
>    )
>
>
>
>
>
>
> -------------------------------------------------
> Tks        | <mailto:BVance at sbm.com>
> BV         | <mailto:BobVance at alumni.caltech.edu>
> Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
> Vox 770-623-3430           11455 Lakefield Dr.
> Fax 770-623-3429           Duluth, GA 30097-1511
> =================================================
>
>
>
>
>
>
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET:
Mark.Andrews at nominum.com