blanks in owner and host names
Mark.Andrews at nominum.com
Mark.Andrews at nominum.com
Sun Jan 14 08:06:09 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 "."
Yes.
> 2) also stored in memory cache as 0x20
BIND 9 stores a space, BIND 8 uses presentation internally.
> 3) converted to "\032" for display purposes, such as a dump of
> cache or any other "presentation"
Yes.
> 4) saved in the zone, ixfr, and log files as "\032" since interpretation
> of these files relies on whitespace delimitation.
Yes.
> 5) when the \032 is encountered in those data files, it converts
> it to 0x20 for internal consumption and query responses.
Yes.
>
>
>
> >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
>
>
>
>
>
--
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