ietf
[Top] [All Lists]

Re: Bonjour-dev Digest, Vol 10, Issue 19

2013-02-21 18:37:05

In message <3E07105E-58DC-4E08-AC9F-D259A0A4B16F(_at_)me(_dot_)com>, Sabahattin 
Gucukoglu 
writes:
(Because this was brought up very, very recently.)

On 21 Feb 2013, at 20:28, Rick Mann <rmann(_at_)latencyzero(_dot_)com> wrote:
On Feb 21, 2013, at 12:24 , David Brower 
<david(_dot_)brower(_at_)oracle(_dot_)com> 
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(_at_)isc(_dot_)org

<Prev in Thread] Current Thread [Next in Thread>