In message <3E07105E-58DC-4E08-AC9F-D259A0A4B16F@xxxxxx>, Sabahattin Gucukoglu
writes:
> (Because this was brought up very, very recently.)
>
> On 21 Feb 2013, at 20:28, Rick Mann <rmann@xxxxxxxxxxxxxxx> wrote:
> > On Feb 21, 2013, at 12:24 , David Brower <david.brower@xxxxxxxxxx>
> wrote:
> >> It depends on the records. If you phrase it like you that, you will
> >> probably get the blank stare answer. When you start talking about the
> >> PTR, SRV and TXT records specifically, then you'll have a case -- but it
> >> isn't really Bonjour that is the proximate force, because those were
> >> issues against interpretations of the previous RFCs.
> >>
> >> Now, the legalistic point I'm debating at the moment is whether it is
> >> proper and/or legal to have the SRV record use as the target name the
> >> string version of an ip4 address, eg: "192.169.0.145". That's a
> >> perfectly legal and representable set of characters for a hostname, so
> >> maybe OK.
Actually it isn't a legal hostname if it is supposed to be a fully
qualified host name as all digit tlds are prohibited in valid host
names. RFC 1123
> >> How about for an ip6 address with colons, which aren't allowed in
> >> hostnames?
> >
> > All I know is that a couple years ago, I tried and failed with both
> > DynDNS and DNSMadeEasy to get them to allow me to put spaces in TXT
> > records. I cited all relevant material I could find, but they kept going
> > back to the original DNS specifications saying those didn't allow spaces.
RFC 1035 permits spaces in TXT records.
RFC 1035 permits spaces in domain names.
You either using a " delimited string or \032 to represent a space.
RFC 1035:
<character-string> is expressed in one or two ways: as a contiguous set
of characters without interior spaces, or as a string beginning with a "
and ending with a ". Inside a " delimited string any character can
occur, except for a " itself, which must be quoted using \ (back slash).
\DDD where each D is a digit is the octet corresponding to
the decimal number described by DDD. The resulting
octet is assumed to be text and is not checked for
special meaning.
DynDNS and DNSMadeEasy are wrong in this respect.
> RFC 1035, 2.3.1, wisely advises the use of compatible constraints on
> labels in host names. I am aware that DNS is binary transparent, and
> mDNS/DNS-SD make use of that feature to be useful, but I can well
> understand the scepticism of your DNS hosts. Perhaps this is a
> legitimate call to relax the restrictions, *if* the operator/user is
> aware of the potential consequences.
>
> Cheers,
> Sabahattin
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx