all digits non-FQDN won't resolve!

[Mark_Andrews at isc.org]

> 
> On 23 Dec 2001 phn at icke-reklam.ipsec.nu wrote:
> 
> > Date: 23 Dec 2001 08:57:43 GMT
> > From: phn at icke-reklam.ipsec.nu
> > To: comp-protocols-dns-bind at moderators.isc.org
> > Newsgroups: comp.protocols.dns.bind
> > Subject: Re: all digits  non-FQDN won't resolve!
> >
> >
> > Farid Hamjavar <hamjavar at unm.edu> wrote:
> >
> >
> > > bind 8.2.5 aix 4.3.3
> >
> > > Greetings,
> >
> > > This post is not about hostname syntax, as far as I know,
> > > hostnames with all digits are valid (e.g. 123450987.foobar.org)
> > Nope they arn't
> 
> all digit host names  appear to be very legal.
> 
> 
> RFC952 says:
>    <name>  ::=3D <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
> 
> 
> RFC1123 says:
>   The syntax of a legal Internet host name was specified in RFC-952
>   [DNS:4].  One aspect of host name syntax is hereby changed: the
>   restriction on the first character is relaxed to allow either a
>   letter or a digit.  Host software MUST support this more liberal
>   syntax.


	Application often use inet_addr() to check input strings
	to see if that are raw IP addresses.  A raw 32 bit number
	is a perfectly good IP address as far as inet_addr() is
	concerned.

	inet_pton() however is restricted to decimal quad for IPv4
	and newer apps tend to use it as it is also required for
	IPv6.

	So despite it being legal it will still mis-match when the
	application is also prepared to handle raw IPv4 addresses.

	Mark

INTERNET ADDRESSES
     Values specified using the `.' notation take one of the following forms:

           a.b.c.d
           a.b.c
           a.b
           a

     When four parts are specified, each is interpreted as a byte of data and
     assigned, from left to right, to the four bytes of an Internet address.
     Note that when an Internet address is viewed as a 32-bit integer quantity
     on the VAX the bytes referred to above appear as ``d.c.b.a''.  That is,
     VAX bytes are ordered from right to left.

     When a three part address is specified, the last part is interpreted as a
     16-bit quantity and placed in the right-most two bytes of the network
     address.  This makes the three part address format convenient for speci-
     fying Class B network addresses as ``128.net.host''.

     When a two part address is supplied, the last part is interpreted as a
     24-bit quantity and placed in the right most three bytes of the network
     address.  This makes the two part address format convenient for specify-
     ing Class A network addresses as ``net.host''.

     When only one part is given, the value is stored directly in the network
     address without any byte rearrangement.

     All numbers supplied as ``parts'' in a `.' notation may be decimal,
     octal, or hexadecimal, as specified in the C language (i.e., a leading 0x
     or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other-
     wise, the number is interpreted as decimal).


> 
> 
> 
> 
> Farid
> UNM
> 
> 
> 
> 
> 
> 
> > RFC952 is still valid, the reason is clarity, a hostname
> > consisting of digits-only could be interpreted as an address.
> >
> >
> >
> > > We have this strange behavior on a handful of our hosts
> > > whose name happen to be made up of all digits.
> >
> > > nslookup and host and dig all behave in this
> > > strange way:
> >
> >
> > > if host is looked up in non-FQDN,  query fails and
> > > no answer is returned. However, if in FQDN format,
> > > everything is OK.
> >
> >
> > > So two questions:
> >
> > > 1] Why this behavior for hosts whose name is all  digits?
> > The fully-numeric hostname is misinterpreted. Change your habits.
> >
> > > 2] Why this behavior can not be produced for
> > >    other hostnames?
> >
> >
> > > Thanks,
> > > Farid
> > > UNM
> >
> >
> >
> >
> > --
> > Peter H=E5kanson
> >         IPSec  Sverige      (At the Riverside of Gothenburg, home of Volv=
> o)
> >            Sorry about my e-mail address, but i'm trying to keep spam out=
> =2E
> > =09   Remove "icke-reklam" and it works.
> >
> 
> 
> 
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org