blanks in owner and host names
Mark.Andrews at nominum.com
Mark.Andrews at nominum.com
Sat Jan 13 11:40:42 UTC 2001
>
> >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