blanks in owner and host names
Bob Vance
bobvance at alumni.caltech.edu
Sat Jan 13 17:50:31 UTC 2001
Thanks, Mark.
I think that I'm seeing the light. I was led a little astray by the
fact this arose out of a dynamic update from DHCP and that there is a
minor bug in dhcpd in this regard as well. I was not seeing the tree
because of the forest [sic] :)
>>> Note that 'dhcpd' is *changing* those blanks to \032, so BIND
>> is never really "seeing" a blank.
>It's a space.
>\032 is sent as a space on the wire.
Oh. So, you are saying that when 'dig' and 'nslookup' show the
QUERY SECTION: with "\032", that's just for our consumption (hence
"presentation") and that the packet *actually* has a " " in it when it's
sent?
I guess I was confused because the zone, ixfr, and log files all had
the blanks converted to "\032" and so I thought that this was, in a
sense, a real conversion to avoid dealing with " " permanently. Of
course, that would have meant that, practically speaking, that the name
no longer really had spaces in it -- resolver code would have to convert
requests to the "real", \032 name in the packet so we could still think
that it had blanks in it.
So, let me see whether I've got anything straight:
Whenever a blank (and some other special chars, I presume) is
encountered in a name, then it is:
1) sent in data packets as is (i.e., " " , char (0x20) ).
makes sense, since the packet format for labels is [len][len octets]
so *any* char, theoretically, would be allowed -- even "."
2) also stored in memory cache as 0x20
3) converted to "\032" for display purposes, such as a dump of
cache or any other "presentation"
4) saved in the zone, ixfr, and log files as "\032" since interpretation
of these files relies on whitespace delimitation.
5) when the \032 is encountered in those data files, it converts
it to 0x20 for internal consumption and query responses.
>read RFC 952
> > Why is BIND complaining?
>Because it was configured to.
Duh!
I'm aware of the invalid char in names.
But, because of the above confusion concerning \032 (and the extra
meaning which I was reading into it), I didn't realize that this was
just another case similar to the infamous "_" invalid char.
Or maybe I was just too tired to think straight.
I had completely forgotten that I have a
check-names master warn;
in my config file !!
Doh!
Of course, this is a slightly more complex situation than "_",
because of the whitespace delimiter.
-------------------------------------------------
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: Saturday, January 13, 2001 6:41 AM
To: bobvance at alumni.caltech.edu
Cc: bind-users at isc.org
Subject: Re: blanks in owner and host names
>
> >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?
Go read RFC 952 what defines what is legal in a hostname.
RFC 1123 relaced the definition to allow leading digits.
> Note that 'dhcpd' is *changing* those blanks to \032, so BIND
> is never really "seeing" a blank.
It's a space.
> 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.
\032 is sent as a space on the wire.
>
> 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?
It complains because the name is not a legal hostname.
Mark
>
>
> -------------------------------------------------
> 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
>
>
>
>
>
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET:
Mark.Andrews at nominum.com
More information about the bind-users
mailing list