Re: CVS commit: src/lib/libc/net

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 04 Nov 2015 14:02:12 +0100 (CET)
    From:        Havard Eidnes <he%NetBSD.org@localhost>
    Message-ID:  <20151104.140212.184674982.he%uninett.no@localhost>

  | 952, referred to from 1123.

That's just fine if your intent is to put a host name in HOSTS.TXT
That's all 952 applies to.   If that is your intent, then certainly
you must comply with its syntax.

  | I beleive that in the context of the DNS, the customary
  | definition of a hostname is a DNS name which has either an A or a
  | AAAA record registered on it.

Where does that definition come from?   Customary where?   The only
explanation for that assumption I can imagine, is that HOSTS.TXT just
bound names to addresses, so the part of the DNS that does the same
could be considered to be mapping host names too - but that doesn't
(in any way) imply that the 952 syntax for names applies to anything
in the DNS, it (if it even exists) would just be a shorthand terminology.

If the DNS spec had wanted to limit the syntax of names, or even the
syntax of some names (which would be a truly bizarre design decision)
then it would have done so explicitly.

On the contrary, pains were taken to ensure that no such requirements
would be necessary, with all DNS names being explicitly octet strings
with an explicit length field, so no internal decoding would be required.
(that is aside from the A==a stuff, which was understandable at the time,
but is a true nuisance now.)

  | If I'm not much mistaken, that's
  | the interpretation implemented by BIND's "check-names" feature:

check-names in general is a botch, and should never have been implemented.

As it applies to primary zone files, it is OK, in that sites are free
to put whatever syntax/semantic meanings they like on their own names,
and if they do, refusing to load a zone in which someone has accidentally
violated the rules, is a reasonable way to enforce the policy.   For that,
check-names is ok, though gives sites almost no control over what policy
they'd like to implement.

For secondary zones, and the cache, it is utter nonsense, and should be
removed (and if not removed, should certainly be disabled.)

  | I'm not entirely certain I agree.  If you're looking up A or AAAA
  | information, you're looking up a host name,

If that's how you have defined host name, then yes.

  | and some syntactical restrictions may apply 

They maybe some, but what restrictions?   It all depends on how the name is
to be used.  For obtaining the address, there is no need for any restriction
at all, the DNS can handle anything, but where the name is going to be used
in some other way, there may very well be all kinds of restructions.

But how can you possibly expect the name lookup routines to understand that?

  | if you wish to adhere to the restrictions in RFC 952.

If you wish to adhere to those rules for some reason, then you only create
names that comply, and you can ignore lookup attempts - if something looks
up a name that doesn't comply, it will simply fail to be found.

That is, even if you believe there should be some syntax requirement on names,
implementing that in the name lookup is the wrong place to do it, the correct
way is to limit the names that can be created in the first place.   That
would be check-names on a primary zone, or similar.

kre