Subject: RE: I-D ACTION:draft-ietf-dnsind-rfc2052bis-00.txt

From: Stuart Kwan <[email-masked]>
Date: Fri, 30 Oct 1998 15:12:16 -0800

Based on the technical feedback posted to the list, I am withdrawing my
objection to the changes in draft-ietf-dnsind-rfc2052bis-00.txt.  I am in
favor of putting the leading underscores back into the record names.  Let's
submit this to the IESG and get it on standards track.

Microsoft will support this format in Windows 2000.

Cheers,
- Stuart

> -----Original Message-----
> From:	Paul A Vixie [SMTP:[email-masked]]
> Sent:	Friday, September 04, 1998 11:13 AM
> To:	[email-masked]
> Subject:	Re: I-D ACTION:draft-ietf-dnsind-rfc2052bis-00.txt 
> 
> > Microsoft Windows NT 5.0 makes heavy use of the SRV RR, mainly for the
> > location of Active Directory servers.  In the recently shipped Beta 2
> > release of WinNT 5.0, Active Directory domain controllers use the
> dynamic
> > update protocol to register SRV RRs.  Active Directory clients query for
> SRV
> > RRs.  The current code uses RFC2052-spec names (no leading underscores).
> > 
> > WinNT 5.0 could be characterized as an "Early Adopter" of the
> (experimental)
> > SRV RR.  To prevent future incompatibilites, we would prefer that the
> > leading underscore not be reintroduced into the spec.
> 
> My take on this is: that the RFC Editor made an unrepresented change to
> the final draft, for reasons which remain unclear to me, and that RFC 2052
> does not represent the intent of its authors; and, since deployed code now
> requires the RFC Editor's erroneous version to be made permanent, we ought
> to just leave the RFC Editor's change in place and hope for the best.
> 
> My original goal in adding the _'s was to ensure that these records would
> never conflict with host or mail names.  But my original reasoning, sound
> and conservative though I still feel it to have been, is not strong enough
> to break Microsoft's installed base, even if the software is only in Beta.
> 
> Therefore unless I receive compelling argument in favour of reverting to
> the authors' intent (abandoning the RFC Editor's changes, in other words),
> then the next version of the RFC2052bis draft will differ in no
> substantial
> way from RFC2052 itself.  I'll take this matter up privately with the RFC
> Editor to try to keep this kind of change from creeping in again in the
> future.

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Oct 1998 23:07:58 -0800 (PST)

> i agree with stuart kwan's suggestion: rfc2052-bis is ready to go up.  kre?
> should we have a WG lastcall?

Certainly if it is to be given to the IESG as a document to be progressed,
we should.  Especially as it has been little discussed here, and not at all
in Chicago, as I remember.

Are Arnt and you proposing it as standards track?

randy

---

From: Paul A Vixie <[email-masked]>
Date: Fri, 30 Oct 1998 23:00:14 -0800

however, my comments about the rfc editor:

> does not represent the intent of its authors; ...
>                     ... I'll take this matter up privately with the RFC

...were ill considered and are hereby withdrawn.  the removal of the _ was
indeed an error but it was mine, not Jon's, and had i checked my own archives
before posting the above drivel i would have known better.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sat, 31 Oct 1998 09:19:11 -0500

Well, I just re-read this draft and I have a few comments. all but one
minor.

(1) Although asdf.com, which is used for the examples, does not
currently exist, it could in the future.  I suggest globally replacing
it in the draft with example.com or asdf.example.

(2) Probably the most serious thing is the wildcard question about
which there has been previous correspondence (see message from Andrew
Draper and my reply appended below).  A wildcard is commonly used
today in MX, for example, to cause mail for all names in the wildcard
scope to go to a particular set of servers.  But wildcards in the
current DNS are restricted to the leftmost label in the owner name
wheras with SRV you would like to be able to put an asterisk after the
service and protocol, such as _smtp._tcp.*.example.com.  The idea is
that this would match queries such as
_smtp._tcp.specific.name.example.com. I don't know how difficult it
would be to extend wildcard processing although it seems to me that as
long as you are claerly restricted to a single asterisk, it should not be too
bad.  As per my message below, this causes complications for DNSSEC
for which there are, it seems to me, three soltuions: (1) change the
SIG RR to explicitly accomodate the embedded asterisk case, (2) have
some logic based on the leading underscore in the SRV name prefix
labels, and (3) don't expand the asertick in answers for non-leading
asterisks. 

(3) The draft mentions A RRs but never AAAA RRs.  Seems like something
should be done about this even if it's only one sentence somewhere
that says references to A RRs include AAAA RRs.

(4) kre a while ago asked if this was applicable to DNS, ICMP, etc.
I.E., are you supposed to do an DNS retrieval to figure out where to
send DNS queries or pings to.  Presumably not and something could be
mentioned about this.

I support advancement of this draft on the standards track. For most
of the above I'd be happy to abide by the authors decisions on whether
they want to diddle the draft.  After all, its only going for proposed
and most of the sorts of changes suggested above could easily be made
at the draft standard level.  However, I would like some clearer
resolution of the wildcard issue.  It seems like a problem, some
messages have been posted on it, and there has been no response.

Thanks,
Donald

From:  Stuart Kwan <[email-masked]>
Message-ID:  <B9D1827FDF66D111925800805F3102E3078AC833@RED-MSG-57>
To:  "'Paul A Vixie'" <[email-masked]>, [email-masked]
Date:  Fri, 30 Oct 1998 15:12:16 -0800
Sender:  [email-masked]

>> ...

Message-Id: <[email-masked]>
To: "Namedroppers mailing list" <[email-masked]>
Subject: Re: Wildcards and SRV records 
In-reply-to: Your message of "Mon, 07 Sep 1998 16:21:10 BST."
             <[email-masked]> 
Date: Sun, 11 Oct 1998 20:59:44 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]

I don't recall seeing any answer to the message below.  Inability to
do SRV wildcarding seems like a defect.  Extending * to permit one
star label either at the beginning or interior to an owner name seems
to fix that.  I don't see any particular advantage in all the "_"
restrictions suggestyed below.  But if an interior "*" acts pretty
much like current wildcards and returns an answer with a complete
synthesized name, you have a real problem with DNSSEC.  In particular,
the SIG covering the wildcard RR in the zone covers the form with the
"*" (since you can't precalculate signatures over the approximately
infinite number of substitutions that could occur).  With just a
leading *, this is easy because there are not many possibilities and
the original length is encoded into the SIG.  But with an interior
star, either SIG would have to change to permit more information about
the original owner name or you need to start just returning the
wildcard name for without substitution...

Thanks,
Donald

From:  Andrew Draper <[email-masked]>
Message-ID:  <[email-masked]>
To:  "Namedroppers mailing list" <[email-masked]>
Date:  Mon, 7 Sep 1998 16:21:10 +0100 

>The current DNS specs allow for the use of wildcard records to "fill in" host 
>names which do not exist, for example:
>
>*.madge.com.            IN  MX 50 mailserver.madge.com.
>
>If I were to try and do this using the SRV record then I suppose that I would
>end up with a record such as:
>
>_smtp._tcp.*.madge.com. IN SRV 50 0 25 mailserver.madge.com.
>
>By my reading of RFC1034 this is illegal (wildcards can only appear as the
>first label in an name).
>
>While this does not seem useful in the case of SMTP (the owner of a domain
>could just use MX records instead) there are probably other protocols where
>wildcard records will be needed.  One example is h.323, where a lookup for
>SRV records is being proposed as the method of resolving an email-address
>into the address of a server which can be used to contact the person
>specified.
>
>To implement this I suggest that we should define a new type of wildcard
>record - for the sake of description call this a non-underscore wildcard and
>represent it as "*_" within zone files (although better names and
>representations are probably possible).
>
>The non-underscore wildcard is allowed to be present as the leftmost label
>of a name, or following one or more labels which start with underscores, but
>not following labels which don't start with underscores.  Only one
>non-underscore wildcard is allowed in a name.
>
>The non-underscore wildcard matches one or more labels which don't start
>with an underscore, providing that the labels to the left and right of the
>wildcard all match.
>
>Obviously, implementation of the non-underscore wildcard would be optional
>for a server, and transparent for a client.  It requires no changes to bits
>on the wire.
>
>It does however mean that it must be possible for a server to tell whether a
>label is part of a standard domain label or is the service or protocol value
>for a SRV lookup.  I would thus prefer that the underscores remain in the
>definition of the SRV record.
>
>Is the non-underscore wildcard a good idea?
>
>Regards,
>
>    Andy.
>
>-- 
>Andrew Draper - Principal Development Engineer - WAVE Software
>Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks.
>mailto:[email-masked]  phone:+44 1753 661329
>pgp fingerprint D6 ED 72 4F 96 BB CA 2D  68 74 4C E0 CB B9 0B 3F