blanks in owner and host names

Danny Mayer mayer at gis.net
Sat Jan 13 16:55:08 UTC 2001


         I'm not sure what you are expecting.  The fact that they encoded a
   name in firmware is irrelevant since DNS doesn't use that name, it uses the
   name YOU provide.  You don't have to give the system itselfa name at all,
   as long has it has an IP address.  In your configuration drop the space or
   use a hyphen and you don't have any problem.  You are NOT forced to use
   the name in the firmware, it's just a convenience.  In any case, it's not hard to
   upgrade the firmware.  These days everything's stored in flashrom and
   can be easily modified.  You are working very hard for no payback, violating
   the specs for DNS, to get something to work that shouldn't work.

         Danny

At 11:35 PM 1/12/01, Mark.Andrews at nominum.com wrote:

> > 
> > 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




More information about the bind-users mailing list