Subject: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace

From: Joe Touch <[email-masked]>
Date: Sun, 11 Sep 2011 13:12:29 -0700

Hi, all,

I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC [email-masked] if you reply to or forward this review.

This document describes the use of DNS SRV records to coordinate NFS4 use and a global file namespace across a groups of clients and servers.

There are no transport protocol issues in this document. The key transport issue is the definition of a new DNS SRV record and its associated syntax.

There are issues with the intended syntax of the proposed DNS SRV record. The current syntax is defined in RFC 2782 as:

	_service._transport.NAME

	service is an IANA SRV name, the namespace of which is defined in RFC 6335

	transport is _TCP or _UDP

	NAME is a DNS FQDN

Given other considerations below (on versioning), the record should be one of the following

	_nfs._tcp.example.com TTL Class SRV Priority Weight Port Target
	_nfs._udp.example.com TTL Class SRV Priority Weight Port Target

All other information specific to the exchange, e.g., organization (which may or may not be a suffix of the Target, FWIW), desired mount point, and various NFS-specific capabilities (e.g., mount options) ought to be expressed in an associated TXT record as defined fields, as is the case with other services that use SRV records. These options can have defaults if not otherwise present.

Some other issues are discussed below.

Overall, the above is the key concern, and needs to be addressed before proceeding. Issues below are indicated as either critical or suggestions for clarification.

Joe

------------------------

Critical issues:

- the IANA section is incomplete
This document needs to request IANA assign an SRV service name, e.g.:

	SRV	nfs	TCP
	SRV	nfs	UDP

It is not clear whether an additional assignment of "SRV nfs SCTP" is required; recent discussions on other SCTP SRV uses suggest that UDP is indexed in these cases instead. This might warrant further discussion.

- the service name should not include the version number
As per RFC 6335, and to be consistent with the existing port assignments for NFS Version 4.

- the discussion of list of organizations as with root.afs should be described in a little more detail
The current sentence is a bit cryptic; this could be a full paragraph, perhaps with an example.

- there is no appropriate place to indicate write vs read-only in the DNS request
The DNS request should return all available options, and indicate write vs. read-only in the associated TXT records. The client should then determine which is desired.

----------------------

Other issues (intended as suggestions):

- version 4
Throughout this document, "version 4" is used wherever NFS is used. Since V4 (more specifically, 4.1) is the current common version, it does not seem necessary to include this marking in most places except where differences in the NFS versions are being highlighted.

- colloquial advice
Terms like "appropriate" and "useful" should be removed throughout. They represent judgements whose evaluation criteria is not discussed.

- overall writing style
The document is written in the tense and style of a proposal. It should be revised to read as the intended specification it will become. "We propose" and "We use", and similar styles should be replaced with "this document specifies" and "this record uses".

- clarify overloaded terms
Terms like "root" and "name space" are widely used in different ways in the DNS and file systems. Because this document combines the two, each use should be clarified by a preceding term, e.g., DNS name space or file system name space, DNS root or file system root.

- the use of RFC 2119 terms should be reviewed
In particular, SHOULD should be used only where a specific exception is currently known or suspected, and that exception described. This provides the motivation for the selection of SHOULD vs. MAY or MUST.

- the discussion of client vs server implementation (sec 4.3, as well as partly in sec 4.2) should consider client-specific DNS responses
The DNS could provide responses that vary based on the IP of the client. This could be a desirable feature. Further, the client knows whether it wants write or read-write copies. AFAICT, the client is not only the better place to implement this capability, it is the only viable place.

- I found the hidden directory name discussion odd
It does not make sense to overload read-only with directory visibility; these are orthogonal issues. The desired mount point should be indicated in the TXT record; if a default convention is desired, it should be indicated in the description of that field.

- the AMD reference is only a web page
Not sure which particular reference is best, but a permanent reference would be useful, e.g.: Matthew Crosby. 1997. AMD—AutoMount Daemon. Linux J. 1997, 35es, Article 4 (March 1997).

-----

---

From: Keith Moore <[email-masked]>
Date: Sun, 11 Sep 2011 16:22:34 -0400

I've always thought that insistence on the use of RFC 2782 labels with SRV records unreasonably overconstrained the use of SRV records; and thus, limited their applicability.  

Part of the problem, I suspect, is that at the time that 2782 was being drafted there may have been some belief that SRV records could reasonably be retroactively applied to all existing protocols, and thus there would be a need for a uniform syntax for DNS labels used with SRV records.  But if (as is IMO appropriate) SRV records are only used with applications that are specified to use them, there is little benefit for the format of DNS labels used with SRV to be uniform across all uses of SRV.  

(I won't say "no benefit".  A DNS API designed to facilitate easy SRV record lookup might benefit from a standard label syntax, but even then, it would make more sense to not embed that knowledge in the API and let the application construct the label to be queried.)

So IMO all uses of SRV records should not be constrained to use RFC 2782 DNS labels.

Keith

On Sep 11, 2011, at 4:12 PM, Joe Touch wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Joe Touch <[email-masked]>
Date: Sun, 11 Sep 2011 13:46:29 -0700

Hi Keith,

On 9/11/2011 1:22 PM, Keith Moore wrote:
> I've always thought that insistence on the use of RFC 2782 labels
> with SRV records unreasonably overconstrained the use of SRV records;
> and thus, limited their applicability.
>
> Part of the problem, I suspect, is that at the time that 2782 was
> being drafted there may have been some belief that SRV records could
> reasonably be retroactively applied to all existing protocols, and thus
> there would be a need for a uniform syntax for DNS labels used with SRV
> records. But if (as is IMO appropriate) SRV records are only used with
> applications that are specified to use them, there is little benefit for
> the format of DNS labels used with SRV to be uniform across all uses of SRV.
>
> (I won't say "no benefit". A DNS API designed to facilitate easy SRV
> record lookup might benefit from a standard label syntax, but even then,
> it would make more sense to not embed that knowledge in the API and let
> the application construct the label to be queried.)
>

We've been discussing this in the Transport area lately.

DNS SRVs are defined in RFC 2782 as I have described. Additional info is 
passed in TXT records for current DNS SRVs.

I.e. what I have proposed is what is both current spec and current 
widespread practice.

Before proposing a change (which would need to happen before we would 
use it in a new spec anyway), is there something the current syntax (and 
use of TXTs for additional info) cannot do that you want?

Joe

---

From: Keith Moore <[email-masked]>
Date: Sun, 11 Sep 2011 17:09:46 -0400

On Sep 11, 2011, at 4:46 PM, Joe Touch wrote:

> DNS SRVs are defined in RFC 2782 as I have described. Additional info is passed in TXT records for current DNS SRVs.
> 
> I.e. what I have proposed is what is both current spec and current widespread practice.
> 
> Before proposing a change (which would need to happen before we would use it in a new spec anyway), is there something the current syntax (and use of TXTs for additional info) cannot do that you want?

Why use SRV records at all if you also need TXT records to convey part of the information needed by apps (and thus, have to do multiple queries for the same level of information)?  Why not just encode all of the information in TXT records?

Keith

---

From: Joe Touch <[email-masked]>
Date: Sun, 11 Sep 2011 15:23:33 -0700

> Why use SRV records at all if you also need TXT records to convey part of the information needed by apps (and thus, have to do multiple queries for the same level of information)?  Why not just enc…

The SRV records provide a standard way of mapping a service (as per the IANA ports and service names registry) on a specific transport to a hostname and port number.

The TXT records are linked to the SRV records, and provide additional bootstrap info that the service does not provide in-band.

If you're looking for a more generic database query system, you might consider using LDAP rather than the DNS.

Joe

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Sep 2011 02:32:36 -0400

> The TXT records are linked to the SRV records, and provide additional bootstrap info that the service does not provide in-band.

You did not answer the question.

> If you're looking for a more generic database query system, you might consider using LDAP rather than the DNS.

I'm not looking for anything in particular.   I just don't see any justification for insisting that SRV records always be used with RFC 2782 style labels.  Nor do I immediately see any justification for using SRV at all if the application also needs to look up TXT records to get the service's profile.

Of course, one of the problems with using SRV more widely (in addition to backward compatibility issues) is that in many cases what's desired is not merely to map a service name (as defined in the IANA registry and equated with a default port) onto an address and port, but rather, to provide instructions as to how a service may be accessed - a service profile, if you will. So I can certainly see why SRV alone would not do the job.  What I don't immediately see is why it's worth the trouble of using SRV at all for those cases when it won't do the job.

(LDAP by itself wouldn't solve this problem either - you'd still need to define a way to represent an application service profile in LDAP.  And if the name of the service is reasonably represented by a DNS name, then arguably, the profile belongs in DNS.  Or at least, a pointer to the profile belongs in DNS.  The last thing we need is to have LDAP and DNS providing conflicting information about what a DNS name means.)

Keith

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 07:57:19 -0700

> You did not answer the question.

I had assumed familiarity with how SRV and TXT records are used 
together. See: draft-cheshire-dnsext-dns-sd

The SRV record has the semantic structure that allows the DNS query to 
be processed, e.g., weight, port number, target, etc.

The TXT record of the same name gives the additional information needed 
for service bootstrap.

> I'm not looking for anything in particular. I just don't see any
> justification for insisting that SRV records always be used with RFC
> 2782 style labels.

I have provided two:

	1) that's the current standard (i.e., changing it requires
	an update to RFC 2782, which this draft does not request)

	2) service lookups already depend on the semantic structure of
	IANA service names, which is already only [name, transport]

Adding further structure to these entities requires both a change to the 
standard and a change to the registry.

> Nor do I immediately see any justification for using
> SRV at all if the application also needs to look up TXT records to get
> the service's profile.

SRV records specify the structure that yields the port number, target, 
weight, etc.

Sure, you could define TXT record fields for anything you wanted - 
effectively redefining the DNS inside TXT records. However, you would 
also need to define an indicator *required in all TXT records* that 
would tell you whether to interpret the contents as A, AAAA, CNAME, SRV, 
etc.

Right now, the DNS indicates these as separate RR types. Stuart's draft 
defines TXT's with names matching corresponding SRV records as having 
additional info.

Yes, you could just have the TXT record, but you'd then need to define 
the SRV info in the TXT record as fields. For at many services, 
additional fields beyond the SRV info isn't needed.

> Of course, one of the problems with using SRV more widely (in
> addition to backward compatibility issues) is that in many cases
> what's desired is not merely to map a service name (as defined in the
> IANA registry and equated with a default port) onto an address and
> port, but rather, to provide instructions as to how a service may be
> accessed - a service profile, if you will. So I can certainly see why
> SRV alone would not do the job. What I don't immediately see is why
> it's worth the trouble of using SRV at all for those cases when it
> won't do the job.

The point is that there's one place to get the port number and hostname; 
additional info - which isn't needed in many cases (see the IANA ports 
list) - is added only when needed in these supplemental TXT records.

> (LDAP by itself wouldn't solve this problem either - you'd still
> need to define a way to represent an application service profile in
> LDAP. And if the name of the service is reasonably represented by a
> DNS name, then arguably, the profile belongs in DNS. Or at least, a
> pointer to the profile belongs in DNS. The last thing we need is to
> have LDAP and DNS providing conflicting information about what a DNS
> name means.)

If you want a service that takes [service-description, hostname] and 
returns a [port, hostname, additional-info] tuple, the DNS is fine.

(note that IANA *defines* service description as [name, transport] - 
there's no "read-only" attribute to that query). I.e., this presumes 
that the client parses the "additional-info" and determines whether this 
record is relevant - NOT that the DNS performs this filter for the client.

If you want more sophisticated DNS filters inside the DNS, I'd argue you 
really want LDAP.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 10:39:00 -0700

Hi, Nico,

On 9/12/2011 8:03 AM, Nico Williams wrote:
> I disagree w.r.t. your comments regarding the use of SRV RRs for NFSv4
> domain root location.
>
> I think it would be a mistake to use TXT RRs to encode what SRV RR
> RDATA does just fine just to get around whatever we think the rules
> are or ought to be for using SRV RRs.
>
> However, I'll note that the service here is NOT "NFSv4" but "NFSv4
> domain root", thus, if it would make everybody happy I propose
> changing this:
>
>        _nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
>        _nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net.
>
>
> to this:
>
>        _nfs4domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
>        _nfs4domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net.

That would presume IANA would approve a new service name (i.e., an 
alias) for an existing service/port assignment - RFC 6335 indicates 
otherwise. (it also includes a version number in the string, which the 
same RFC deprecates).

You're locating the NFS service. You're using that to setup a 
domainroot. The former is a DNS SRV issue. The latter is an endhost 
configuration issue. Stuart's draft defining how to use TXT records to 
configure end services is already in widespread use, and sufficient for 
this purpose.

> But IMO this is silly.  For example, Microsoft's Active Directory and
> its Windows (and other) clients use SRV RRs like this:
>
>      _ldap._tcp.gc._msdcs.<domain>
>      _ldap._tcp.<site>._sites.<domain>
>      ...

Microsoft's approach is to basically define a specific pattern to their 
FQDNs - using nonstandard syntax - to indicate that the server is a MS 
product:
http://technet.microsoft.com/en-us/library/cc961719.aspx

I don't agree with this approach; most others who use SRV records use 
TXT fields, and RFC 3088 provides a correct example of SRV use for LDAP.

> If it's time to go update RFC2782, well, let's, but let's not hold up
> the rest of the world over it.

It's up to you if you want to start by redefining SRV records.

This document does not propose to do that, so its use is simply 
noncompliant with existing specs.

Joe

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Sep 2011 13:47:30 -0400

On Sep 12, 2011, at 10:57 AM, Joe Touch wrote:

> I had assumed familiarity with how SRV and TXT records are used together. See: draft-cheshire-dnsext-dns-sd
> 
> The SRV record has the semantic structure that allows the DNS query to be processed, e.g., weight, port number, target, etc.
> 
> The TXT record of the same name gives the additional information needed for service bootstrap.
> 

Yes, but arguably 2782 is a poor fit for this application, and for many other applications also. 

> 	IANA service names, which is already only [name, transport]

There's nothing about the definition of the SRV RR that inherently constrains the label that such RRs are associated with.

> Adding further structure to these entities requires both a change to the standard and a change to the registry.

Well, you can't really change the structure of SRV RRs, as they're already in use for some things and in widely deployed code.  But there's no reason why an app couldn't specify a new use of SRV RRs with different labels than specified by 2782.  As long as there were no potential for collisions between 2782-style labels and the labels used by the app, it wouldn't break anything.  The fact that there's already a standard existing for SRV RR labels shouldn't inherently preclude standardization of a different kind of label associated with SRV.   

> SRV records specify the structure that yields the port number, target, weight, etc.
> 
> Sure, you could define TXT record fields for anything you wanted - effectively redefining the DNS inside TXT records. However, you would also need to define an indicator *required in all TXT records* that would tell you whether to interpret the contents as A, AAAA, CNAME, SRV, etc.

Well, that's the problem with TXT records.  Or, to look at it differently, it's a problem with the design of the DNS protocol in that its way of labeling RR types is too limited.

But looking at it still a different way, if you pick labels that are unique to a particular application, there's no need for a type indicator to be embedded in the TXT record.  (Effectively this is moving the type to the label.)

> Right now, the DNS indicates these as separate RR types. Stuart's draft defines TXT's with names matching corresponding SRV records as having additional info.
> 
> Yes, you could just have the TXT record, but you'd then need to define the SRV info in the TXT record as fields. For at many services, additional fields beyond the SRV info isn't needed.

In principle, the apps that don't need anything beyond what SRV provides could still use the SRV RR as it's defined in 2782 (whether or not the same style of labels are used).    It's (partially) the warts-on-warts approach of TXT + SRV (or NAPTR + SRV, in a different context), that I'm concerned about.   I get the impression that there's a set of people out there who keep insisting that SRV be used even though it turns out not to be a good fit for many situations.  Like this document. 

I've become fairly convinced that SRV is at best not widely applicable, and at worst fairly harmful.    One reason it's not widely applicable is that there are too many cases where the application needs to know more more than a list of (address,port) pairs to successfully choose an instance of a service and use it.   (Part of this is because SRV isn't just being used to help an application connect to a protocol service, but also, to choose an instance of a somewhat more abstract service which might actually be implemented using multiple protocols and/or multiple sets of optional features of a protocol).

One reason it's potentially harmful is that the existence of SRV tempts various parties to think that it's okay to remap ports on the wire and/or to insist that particular ports be used for particular services.  Another reason is that the use of default ports is subtly different from one application to another, and trying to define a RR that treats them all as the same is a Bad Idea.  Once upon a time I ran across an implementation of getaddrinfo() that did SRV lookup by default, and it broke applications that used it in several ways.  

The bottom line for this particular draft is:

- SRV is of more limited applicability than originally assumed, therefore
- there's no need to defend the "purity" of SRV as defined by 2782, therefore
- there's no need to insist that all uses of the SRV RR use the labels as defined in 2782

> The point is that there's one place to get the port number and hostname; additional info - which isn't needed in many cases (see the IANA ports list) - is added only when needed in these supplemental TXT records.

Warts on warts.  Additional query overhead / setup latency, more opportunities for misconfiguration, more opportunities for the TXT and SRV RRs to be out of sync with one another.  etc.

> If you want a service that takes [service-description, hostname] and returns a [port, hostname, additional-info] tuple, the DNS is fine.
> 
> (note that IANA *defines* service description as [name, transport] - there's no "read-only" attribute to that query). I.e., this presumes that the client parses the "additional-info" and determines whether this record is relevant - NOT that the DNS performs this filter for the client.
> 
> If you want more sophisticated DNS filters inside the DNS, I'd argue you really want LDAP.

More warts on warts.  IMO, that's even worse than TXT + SRV, which itself is worse than just using TXT.

Keith

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 11:25:56 -0700

Hi, Keith,

On 9/12/2011 10:47 AM, Keith Moore wrote:
...
> Yes, but arguably 2782 is a poor fit for this application, and for many other applications also.

You're welcome to:

	a) submit a proposal to redefine RFC 2782
or, more usefully AFAICT:
	b) submit a proposal for a new DNS record type

> There's nothing about the definition of the SRV RR that inherently constrains the label that such RRs are associated with.

RFC 2782 specifies the syntax of the label - to the point of stating 
which transports are allowed - not the target, though. That's a place 
you can play if you want, AFAICT.

> Well, you can't really change the structure of SRV RRs, as they're
> already in use for some things and in widely deployed code.  But there's
> no reason why an app couldn't specify a new use of SRV RRs with
> different labels than specified by 2782.

I don't understand what you just said; I agree with the first part, but 
that prevents the second.

> As long as there were no
> potential for collisions between 2782-style labels and the labels used
> by the app, it wouldn't break anything. The fact that there's already a
> standard existing for SRV RR labels shouldn't inherently preclude
> standardization of a different kind of label associated with SRV.

IMO, you're suggesting a new RR, but seem to want all the benefits of 
using SRV with none of the responsibility.

That's not how it works. If you want a new RR, declare it, and deal with 
deployment, etc. If you want to use SRV RRs, either use them as 
specified or change the spec.

> Well, that's the problem with TXT records. Or, to look at it
> differently, it's a problem with the design of the DNS protocol in that
> its way of labeling RR types is too limited.

You're welcome to define a new name service lookup protocol, either 
using LDAP or custom too.

I.e., I agree that RR types are limited, but this WG doesn't get to 
unilaterally redefine SRV types.

> But looking at it still a different way, if you pick labels that are
> unique to a particular application, there's no need for a type indicator
> to be embedded in the TXT record. (Effectively this is moving the type
> to the label.)

If you want to make that argument as a change to RFC 2782, then you need
to propose it in the DNS WG and wait for it to be accepted.

I don't think it will suffice, because for any label structure there 
will be a use outside the intended that wants an exception. That's 
basically the conversation we're having now. You're just kicking the 
ball down the field.

...
>> Yes, you could just have the TXT record, but you'd then need to
define the SRV info in the TXT record as fields. For at many services,
additional fields beyond the SRV info isn't needed.
>
> In principle, the apps that don't need anything beyond what SRV
> provides could still use the SRV RR as it's defined in 2782 (whether or
> not the same style of labels are used). It's (partially) the
> warts-on-warts approach of TXT + SRV (or NAPTR + SRV, in a different
> context), that I'm concerned about. I get the impression that there's a
> set of people out there who keep insisting that SRV be used even though
> it turns out not to be a good fit for many situations. Like this document.

Fair enough. Then don't use SRVs.

> I've become fairly convinced that SRV is at best not widely
> applicable, and at worst fairly harmful. One reason it's not widely
> applicable is that there are too many cases where the application needs
> to know more more than a list of (address,port) pairs to successfully
> choose an instance of a service and use it. (Part of this is because SRV
> isn't just being used to help an application connect to a protocol
> service, but also, to choose an instance of a somewhat more abstract
> service which might actually be implemented using multiple protocols
> and/or multiple sets of optional features of a protocol).

A discussion about this document is not the place to argue for or 
against SRVs, IMO.

This is a separate issue, which would argue (AFAICT) for a new 
structured distributed index system.

> One reason it's potentially harmful is that the existence of SRV
> tempts various parties to think that it's okay to remap ports on the
> wire and/or to insist that particular ports be used for particular
> services. Another reason is that the use of default ports is subtly
> different from one application to another, and trying to define a RR
> that treats them all as the same is a Bad Idea. Once upon a time I ran
> across an implementation of getaddrinfo() that did SRV lookup by
> default, and it broke applications that used it in several ways.

That is not related to this doc either.

> - there's no need to insist that all uses of the SRV RR use the labels as defined in 2782

This document does not update RFC2782. Until this or some other doc 
does, then the "purity" (i.e., spec) stands.

If this (or any other doc) tries to update RFC 2872, we will need to 
have that discussion as a separate thread.

--

My bigger concern is why you insist on wanting to play in the SRV 
sandbox and change the rules, but won't consider defining your own RR, 
or even your own service for lookup.

You can't have it both ways - you cannot benefit from the distribution 
of stable code based on standards and declare that you aren't required 
to follow those standards.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 11:31:07 -0700

Hi, Nico,

On 9/12/2011 10:49 AM, Nico Williams wrote:
> On Mon, Sep 12, 2011 at 12:39 PM, Joe Touch<[email-masked]>  wrote:
>> You're locating the NFS service. You're using that to setup a domainroot.
>> The former is a DNS SRV issue. The latter is an endhost configuration issue.
>
> No.  We do not normally locate the NFS service.  If you know a server,
> that's the server hosting the NFS service.  This is a distinct concept
> to "NFS server".  And the whole point is to avoid end host
> configuration, if by end host you mean the *client*.

Either this is an nfs service or it isn't.

If it is, then it should be using _nfs._tcp.example.com, etc. If it 
isn't, then:
	a) a new service name is required
	which then *requires*
	b) a new port number be assigned

>> I don't agree with this approach; most others who use SRV records use TXT
>> fields, and RFC 3088 provides a correct example of SRV use for LDAP.
>
> I'm uninterested in saying no to plainly working and deployed
> solutions out of dogmatic inflexibility.  Update RFC2782 if you like.

The issue is that if this document wants to go outside the spec, *it* 
needs to update RFC2782 - and survive the discussion that will incur.

If your claim is that we should ignore specs once we find any extant 
exception, then there's simply no point in even proceeding with this 
doc. There's no need for this spec. No need for any spec. Why do you 
even participate in spec discussions then?

> I'm unwilling to do that because I don't believe we have to.
>
> I'm even less willing to use TXT RRs to duplicate SRV RR functionality.

SRV RRs define the port, weight, target, etc.

TXT RRs for the same name provide supplemental information. If you're 
fond of extant implementations driving the argument, why won't you 
consider the dozens of extant SRVs that define TXT fields and already 
use them for exactly this purpose?

Joe

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Sep 2011 14:41:44 -0400

I think at this point we're just talking past each other, but I simply disagree with your assertion that RFC 2782 should be taken as a prohibition on using SRV RRs in any way other than defined in RFC 2782.   

> My bigger concern is why you insist on wanting to play in the SRV sandbox and change the rules, but won't consider defining your own RR, or even your own service for lookup.
> 
> You can't have it both ways - you cannot benefit from the distribution of stable code based on standards and declare that you aren't required to follow those standards.

Frankly, I'm not sure that it's feasible to define a generic service location/selection facility (using DNS or LDAP or anything else) that will be applicable to a wide range of services.

That's why I'm arguing against a Procrustean interpretation of the definition of the SRV RR (trying to make all apps fit into one bed, so to speak).  Let the apps that can make good use of the SRV RR as it's defined do so even if they don't use labels the same way as specified in RFC 2782.    Let the other apps define a way to use use TXT RRs, or define their own RRs.   But I think the mechanism is almost inevitably going to need to be application-specific.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Sep 2011 14:46:00 -0400

On Sep 12, 2011, at 2:31 PM, Joe Touch wrote:

> The issue is that if this document wants to go outside the spec, *it* needs to update RFC2782 - and survive the discussion that will incur.

Well, in a pedantic sense I'm sure that's true.  But it doesn't need to update RFC2782 as it pertains to anything but the ability to locate a certain subset of NFS-based services.  It certainly doesn't have to change how SRV works with respect to other protocols.

Keith

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 12:50:58 -0700

On 9/12/2011 11:41 AM, Keith Moore wrote:
> I think at this point we're just talking past each other, but I
> simply disagree with your assertion that RFC 2782 should be taken as
> a prohibition on using SRV RRs in any way other than defined in RFC
> 2782.

It might be useful to explain to this list what you think a spec means, 
so we can understand what you think it means to comply with a spec.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 12:50:50 -0700

On 9/12/2011 11:46 AM, Keith Moore wrote:
> Well, in a pedantic sense I'm sure that's true. But it doesn't need to
> update RFC2782 as it pertains to anything but the ability to locate a
> certain subset of NFS-based services. It certainly doesn't have to
> change how SRV works with respect to other protocols.

That's trivially true for all protocol variations - they're all as local 
as you define them.

But again if that's your goal - a ships-in-the-night variant - you 
should consider doing declaring a new RR type. That's the point of the 
RR type - to indicate when the interpretation of an RR changes.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 12:56:10 -0700

Hi, Robert,

On 9/12/2011 12:00 PM, Robert Thurlow wrote:
> Joe Touch wrote:
> This doesn't show any real understanding of what we're actually
> trying to do. To recap:
>
> We don't want to enumerate all NFS servers in a domain.

That's what SRV records do. If that's not what you want, you should 
consider defining a new RR type.

> That is
> not an interesting enumeration. We want to find certain ones that
> are known to share a "domain root" (hence the syntax we chose).

That can be accomplished as noted below.

> When we find those servers, we will talk NFSv4 to them (not a new
> service). And we will talk NFSv4 on port 2049 (not a new port).
>
> Your proposal above makes things worse in that it will no longer
> be clear what the SRV record means. It also ensures that we have a
> problem if we ever want to enumerate other subsets of NFS servers
> (none of which have been discussed).

You can enumerate any subset of NFS servers you by differentiatiung them 
in the TXT records or Target fields.

I.e., when you ask for nfs in a domain, you should get back the SRVs for 
all servers in that domain; further filtering should be done on the 
information returned by the client.

To expect otherwise is to confuse the DNS with a true search engine.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 13:08:12 -0700

Hi, Nico,

On 9/12/2011 1:00 PM, Nico Williams wrote:
> On Mon, Sep 12, 2011 at 2:56 PM, Joe Touch<[email-masked]>  wrote:
>> That's what SRV records do. If that's not what you want, you should consider
>> defining a new RR type.
>
> No.... We don't want to enumerate *all* NFSv4 servers in a domain.  We
> want to enumerate all NFSv4 domain-root servers in a domain.  Slight
> difference.

I know what you *want* to do. But short of assigning another port number 
for that capability and getting another service name, this simply isn't 
a service in the IANA service/port numbers sense, so I'm not surprised 
it doesn't uniquely map to SRV records.

> Now, if we only ever intended to discovery domain-root NFSv4 servers,
> then we could just follow RFC2782.  But what if we want to add some
> new role like domain-root, but not domain-root, for NFSv4 servers?  I
> suppose we could punt on this till then, but it seems unclean to do so
> -- it's much cleaner to denote the role of the server ("domain root")
> in the RRset name.

It's never clean to continually redefine the syntax of a structured 
record (SRV). The better solution is to add new fields to the TXT 
record, and filter on that. That's the point - the TXT record use with 
SRV is intended for "all the stuff you might filter on or need for boot" 
that isn't in the SRV record.

Joe

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Sep 2011 16:15:14 -0400

On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:

> It might be useful to explain to this list what you think a spec means, so we can understand what you think it means to comply with a spec.

I think RFC 2782 inappropriately specified SRV RRs by defining both the label syntax and the RDATA syntax at the same time.

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Sep 2011 16:20:47 -0400

On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:

> That's trivially true for all protocol variations - they're all as local as you define them.
> 
> But again if that's your goal - a ships-in-the-night variant - you should consider doing declaring a new RR type. That's the point of the RR type - to indicate when the interpretation of an RR changes.

You and I both know that RR types are limited in number, require significant time and effort to define, and can take many years to deploy to the point where applications can expect to use them.  Which, I suppose, is why people keep trying to use SRV even for situations in which it's poorly suited - it's too much trouble to define and deploy a new one.  

I'm merely suggesting that the 2782 definition should be relaxed a bit and in a way that's compatible with existing DNS server code.   Perhaps the appropriate thing to do is to publish a separate document that updates 2782 and explains this.

Keith

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 13:22:10 -0700

> I think RFC 2782 inappropriately specified SRV RRs by defining both the label syntax and the RDATA syntax at the same time.

How is that different from every other RR except TXT?

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 13:24:00 -0700

On 9/12/2011 1:17 PM, Nico Williams wrote:
> On Mon, Sep 12, 2011 at 3:08 PM, Joe Touch<[email-masked]>  wrote:
>> I know what you *want* to do. But short of assigning another port number for
>> that capability and getting another service name, this simply isn't a
>> service in the IANA service/port numbers sense, so I'm not surprised it
>> doesn't uniquely map to SRV records.
>
> I don't think that's the correct way to go about this.  I see nothing
> wrong with what's proposed.  I say we let the LC run and see where we
> stand on consensus at the end.  If we end up on the rough side of
> consensus, so be it -- in that case then I think we'd want to
> undertake an update of RFC2782, rather than bend to it.  We want to do
> what's right.

I believe have made my position on behalf of the TSVDIR clear.

Joe

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Sep 2011 16:24:30 -0400

On Sep 12, 2011, at 4:23 PM, Nico Williams wrote:

> On Mon, Sep 12, 2011 at 3:15 PM, Keith Moore <[email-masked]> wrote:
> I think we can all agree that RFC2782 is authoritative for the SRV RR
> RDATA specification.  It can be no other way.
> 
> The RRset name, OTOH, we could easily agree that RFC2782 is
> authoritative as to the construction of the RRset name for one use of
> SRV RRs.  I don't see how RFC2782 can constrain forevermore the SRV
> RRset names, but quite clearly there's not much we could or should do
> to change the SRV RR RDATA specification (at most we could change the
> interpretation of some of the RDATA fields in some circumstances, but
> not the RDATA format itself).
> 
> Now, IF the IETF consensus is that we must update RFC2782 in spite of
> the many SRV RR uses that exist which do not match the RFC2782 RRset
> naming convention, well, fine, we can do that -- it's not a big deal,
> only a small delay.  But until then my position is that we do not have
> to do this.

+1

Keith

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 13:31:34 -0700

On 9/12/2011 1:20 PM, Keith Moore wrote:
>>>> The issue is that if this document wants to go outside the
>>>> spec, *it* needs to update RFC2782 - and survive the discussion
>>>> that will incur.
>>>
>>> Well, in a pedantic sense I'm sure that's true. But it doesn't
>>> need to update RFC2782 as it pertains to anything but the ability
>>> to locate a certain subset of NFS-based services. It certainly
>>> doesn't have to change how SRV works with respect to other
>>> protocols.
>>
> You and I both know that RR types are limited in number, require
> significant time and effort to define, and can take many years to
> deploy to the point where applications can expect to use them. Which,
> I suppose, is why people keep trying to use SRV even for situations
> in which it's poorly suited - it's too much trouble to define and
> deploy a new one.

Maybe they use this because it works too.

>> I'm merely suggesting that the 2782 definition should be relaxed a
>> bit and in a way that's compatible with existing DNS server code.
>> Perhaps the appropriate thing to do is to publish a separate
>> document that updates 2782 and explains this.

Start there (but it will be an uphill battle, vs. creating a new RR), 
but then this doc would be held until that change occurs AFAICT.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 13:36:44 -0700

On 9/12/2011 1:23 PM, Nico Williams wrote:
> On Mon, Sep 12, 2011 at 3:15 PM, Keith Moore<[email-masked]>  wrote:

The original DNS spec declared the valid RRset syntax until RFC 2782 
changed it for that RR type.

*That* is the precedent.

If you want another RRset syntax, then you need another RR type IMO. 
That's the only way to ensure that new RRset syntaxes (or RDATA 
syntaxes) will work in all implementations anyway.

Joe

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Sep 2011 16:42:18 -0400

> How is that different from every other RR except TXT?

Most RRs tie some set of data to a domain name which is historically a host name, though in recent years it's become a somewhat more nebulous concept (e.g. "a collection of services", or in the case of MX records "a collection of recipient mailboxes").    SRV is odd in that it overloads the domain to include "service name" and transport protocol.

Part of the problem with the way SRV is defined is that often, "service name" (in the sense of something that's tied to port number, is not what the application is looking for).   Another part of the problem is that "transport protocol" is often not appropriately part of the query - it's something that the application needs to know, rather than something the application should provide when doing the query.

SRV appears to have been designed with the idea that the DNS was a good place to advertise port numbers of services, and that it would make sense to have a standard mechanism to advertise alternate port numbers that would work across all applications.   For a wide variety of reasons, this is not a good idea.  But because SRV already exists and is deployed, and we occasionally find applications that need something similar to SRV, people keep trying to use it in ways that are contrary to its design.  

If DNS were easier to extend - in particular if RR types weren't limited to small integers but rather something like OIDs, and if the format of RDATA weren't hard-coded into DNS servers - I'd absolutely agree that the thing to do would be to deprecate SRV for new applications and define new RR types whenever needed.

Keith

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 13:57:22 -0700

Hi, Keith,

On 9/12/2011 1:42 PM, Keith Moore wrote:
> Most RRs tie some set of data to a domain name which is historically
> a host name, though in recent years it's become a somewhat more
> nebulous concept (e.g. "a collection of services", or in the case of
> MX records "a collection of recipient mailboxes"). SRV is odd in that
> it overloads the domain to include "service name" and transport
> protocol.

Yes - it was defined that way.

> Part of the problem with the way SRV is defined is that often,
> "service name" (in the sense of something that's tied to port number,
> is not what the application is looking for). Another part of the
> problem is that "transport protocol" is often not appropriately part
> of the query - it's something that the application needs to know,
> rather than something the application should provide when doing the
> query.

Yes - this has been a persistent problem in the IANA service/port registry.

Here's where we are today:

	service = L5-L7 inclusive
	transport = L4

It would be useful to have a richer way to describe services, which 
could include:

	- late-binding of transport (or even network)
	- layering of protocols
		e.g., CMD-over-SOAP-over-HTML-over-SSL
	- out-of-band service bootstrap info
	- richer descriptions of service variants
	that support richer searches than DNS supports

Any of these requires an overhaul to the IANA notion of services and 
port numbers, as well as SRV records.

> SRV appears to have been designed with the idea that the DNS was a
> good place to advertise port numbers of services, and that it would
> make sense to have a standard mechanism to advertise alternate port
> numbers that would work across all applications. For a wide variety
> of reasons, this is not a good idea. But because SRV already exists
> and is deployed, and we occasionally find applications that need
> something similar to SRV, people keep trying to use it in ways that
> are contrary to its design.

Port numbers are inherently meaningful only between pairs of consenting 
endpoints. The ability to indicate the local map of service:port seems 
entirely appropriate in an E2E sense. Further, it avoids the burden of 
pre-allocating port numbers (a quite constrained resource) for services 
that might never be used at a given endpoint, and allows that map to be 
assigned dynamically and locally.

Consider that the DNS distributed /etc/hosts, and basically SRVs 
distribute /etc/services

Or would your arguments against SRV use also apply to the DNS? :-)

> If DNS were easier to extend - in particular if RR types weren't
> limited to small integers but rather something like OIDs, and if the
> format of RDATA weren't hard-coded into DNS servers - I'd absolutely
> agree that the thing to do would be to deprecate SRV for new
> applications and define new RR types whenever needed.

OK. So basically you claim that new RR types are bad because they are 
defined in a way that doesn't do what you want.

But then you want to change SRVs - for the same reason you don't want a 
new RR type.

Again, I remain confused as to your position.

My claim is that:

	SRVs represent services as they are currently assigned by IANA

	a new RR could be useful for things that aren't sufficiently
	expressible in the IANA service/port registry

Joe

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Sep 2011 17:39:18 -0400

> Yes - it was defined that way.

It was defined poorly, based on assumptions that were already disconnected from reality and have become even moreso over time.

> It would be useful to have a richer way to describe services, which could include:
> 
> Any of these requires an overhaul to the IANA notion of services and port numbers, as well as SRV records.

It's not clear to me that this would actually be useful, or to put it another way, that defining such a service description mechanism would solve more problems than it creates.  Yes there are corner cases where something like this would be nice.  But do we really need a generic mechanism that encourages so much agility?  Do we want the additional complexity and degraded reliability that would inevitably go along with it?

> Port numbers are inherently meaningful only between pairs of consenting endpoints.

Mumble.  I'd argue that in the case of SMTP at least that port 25 is much more significant than that.   Sure, any given SMTP session could potentially occur over a different port as long as client and server had some mechanism for agreeing to use it.  But the worldwide basis for exchange of email is that MX servers for a domain listen on port 25, and clients know to use port 25 to contact them.  

> The ability to indicate the local map of service:port seems entirely appropriate in an E2E sense.

Actually it breaks the E2E model, by introducing the potential for a third party (in the form of a NAT + DNS server) that expects to be able to mediate between client and server.

> Further, it avoids the burden of pre-allocating port numbers (a quite constrained resource) for services that might never be used at a given endpoint, and allows that map to be assigned dynamically and locally.

Yes, it does that, and I agree that pre-allocated port numbers are precious.  Though I think this particular mechanism causes more problems than it solves.

> Consider that the DNS distributed /etc/hosts, and basically SRVs distribute /etc/services

/etc/services is itself a dubious idea.  When a protocol specification defines a constant port to be used (even if just as a default), and /etc/services purports to override that, that extra layer of indirection harms interoperability.    I remember a time when the MTA for my mail domain dropped a significant amount of mail on the floor because getservbyname("smtp", "tcp") failed (it was implemented in terms of NIS).  I immediately changed the code to replace that line with htons(25), and it never failed again.  Since then, I never use getservbyname when implementing protocol engines, because it's simply wrong to do so.

(Disclaimer: I do use /etc/services as documentation.  e.g. when I want to know which port a particular protocol uses, it's easier to grep /etc/services than it is to look up the port number in the IANA registry.  I just don't use getservbyname whenever I can help doing so.)

> Or would your arguments against SRV use also apply to the DNS? :-)

In general, there's an unfortunate potential for DNS to get out of sync with reality.   DNS as it was originally designed made more sense when all hosts were large boxes that required a significant portion of a room and dedicated air conditioning and power, and thus were mostly immobile.   It's not such a good fit for PCs and even less applicable to mobile hosts.

My preferred way to use DNS for mobile hosts is to have each host be its own authoritative DNS/LLMNR server, with its domains explicitly delegated to it by its parent zones, and replicated from there to secondary servers with stable IP addresses.   That way, the master copy is always in sync with reality, DNS and LLMNR are always in sync, and the replica copies of the zone are always in sync with the master copy whenever the host has network access and the replica servers are reachable.

If DNS were generally implemented that way, using SRV as originally intended would make a bit more sense, because it would take the DNS administrator out of the loop and increase the potential for the DNS and the host to be in sync with one another about which services were running on which ports.  But it would still increase the potential for NATs to cause even more trouble than they do now.  NATs are something that need to be phased out as IPv6 is phased in, not something that need more support and encouragement from the architecture.

> OK. So basically you claim that new RR types are bad because they are defined in a way that doesn't do what you want.

New RR types are what they are.  Some are inevitably defined better than others.  For the specific case of SRV, I don't think the RR was well defined.  But DNS is not as extensible as we'd like, new RR types are scarce and difficult to deploy, and so there's some weight to the idea that we should make do with what we have whenever it doesn't break anything.

> But then you want to change SRVs - for the same reason you don't want a new RR type.

I want to relax the requirements for domain names associated with SRV records.   But the only reason I think that's okay is because I assume that existing DNS servers and client code doesn't enforce the syntax restrictions on domains associated with SRV records.  (given various difficulties with rigidly enforcing such syntax, I think it's unlikely that existing code does that, though perhaps I'm wrong about that).    

> 	expressible in the IANA service/port registry

Agree with that much.  But "services as they're currently assigned by IANA" and that are reasonable to use with SRV are few, and a new RR is difficult to and time-consuming to deploy.   This is a case where I think pragmatic reuse of SRV makes more sense than a purist approach.

Keith

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 15:23:42 -0700

On 9/12/2011 2:39 PM, Keith Moore wrote:
> It was defined poorly, based on assumptions that were already
> disconnected from reality and have become even moreso over time.
>
> It's not clear to me that this would actually be useful, or to put it
> another way, that defining such a service description mechanism would
> solve more problems than it creates. Yes there are corner cases where
> something like this would be nice. But do we really need a generic
> mechanism that /encourages/ so much agility? Do we want the additional
> complexity and degraded reliability that would inevitably go along with it?

Again I'm confused.

You claim there's a clear need to revise SRV syntax, but not the 
registry that basically defines that syntax?

If you don't need a generic mechanism with agility, just use TXT records 
and move on IMO. That's what most other SRV users *have already done*.

If you insist on a clean, generic, system that solves this problem for 
nfsv4 domain-root and other similar cases, you're clearly arguing for 
the deep slog of fixing this throughout the IETF.

> Mumble. I'd argue that in the case of SMTP at least that port 25 is much
> more significant than that. Sure, any given SMTP session could
> potentially occur over a different port as long as client and server had
> some mechanism for agreeing to use it. But the worldwide basis for
> exchange of email is that MX servers for a domain listen on port 25, and
> clients know to use port 25 to contact them.

The worldwide default for services with assigned ports is to assume that 
port number. The worldwide system for doing otherwise is SRV records.

Either one works fine, and either one assumes that both sides make the 
same assumption.

SMTP is not unique in this sense.

The only port that is difficult to change is the DNS. You need to *know* 
that for the host on which the DNS resides for the endpoints you want to 
contact before contacting them.

> Actually it breaks the E2E model, by introducing the potential for a
> third party (in the form of a NAT + DNS server) that expects to be able
> to mediate between client and server.

That "third party" could be at the same endpoint as the destination; in 
that case you'd be using that endpoint's DNS to bootstrap other 
services. Moving that capability to a separate location does compromise 
E2E, but the ability to remap ports has nothing to do with it per se.

Endpoints already can (and do) assume services on ports other than their 
IANA defaults, e.g. The point is that this is an endpoint decision, 
under control of the endpoints.

Yes, it'd be nice to late-bind that without an SRV lookup. I wrote a TCP 
option about that a while back (port names), and there are other similar 
mechanisms that don't use the DNS (TCPMUX).

>> Further, it avoids the burden of pre-allocating port numbers (a quite
>> constrained resource) for services that might never be used at a given
>> endpoint, and allows that map to be assigned dynamically and locally.
>
> Yes, it does that, and I agree that pre-allocated port numbers are
> precious. Though I think this particular mechanism causes more problems
> than it solves.

I don't disagree; I would prefer port-names (for those not familiar, the 
idea was to use the IANA service names as a TCP option in the SYN 
packet, and to demux to the service based on that name string rather 
than the incoming port).

> /etc/services is itself a dubious idea. When a protocol specification
> defines a constant port to be used (even if just as a default), and
> /etc/services purports to override that, that extra layer of indirection
> harms interoperability. I remember a time when the MTA for my mail
> domain dropped a significant amount of mail on the floor because
> getservbyname("smtp", "tcp") failed (it was implemented in terms of
> NIS). I immediately changed the code to replace that line with
> htons(25), and it never failed again. Since then, I never use
> getservbyname when implementing protocol engines, because it's simply
> wrong to do so.

We had this discussion recently elsewhere. You may not want that level 
of indirection when it doesn't do what you want, but others need that 
for other reasons (e.g., to push DNS through a firewall that hijacks it 
otherwise).

Any level of indirection can be abused. But so can any kind of hardwired 
configuration.

> (Disclaimer: I do use /etc/services as documentation. e.g. when I want
> to know which port a particular protocol uses, it's easier to grep
> /etc/services than it is to look up the port number in the IANA
> registry. I just don't use getservbyname whenever I can help doing so.)
>
> In general, there's an unfortunate potential for DNS to get out of sync
> with reality. DNS as it was originally designed made more sense when all
> hosts were large boxes that required a significant portion of a room and
> dedicated air conditioning and power, and thus were mostly immobile.
> It's not such a good fit for PCs and even less applicable to mobile hosts.
>
> My preferred way to use DNS for mobile hosts is to have each host be its
> own authoritative DNS/LLMNR server, with its domains explicitly
> delegated to it by its parent zones, and replicated from there to
> secondary servers with stable IP addresses. That way, the master copy is
> always in sync with reality, DNS and LLMNR are always in sync, and the
> replica copies of the zone are always in sync with the master copy
> whenever the host has network access and the replica servers are reachable.

No disagreement from me, as per my response to the E2E issue above.

> If DNS were generally implemented that way, using SRV as originally
> intended would make a bit more sense, because it would take the DNS
> administrator out of the loop and increase the potential for the DNS and
> the host to be in sync with one another about which services were
> running on which ports. But it would still increase the potential for
> NATs to cause even more trouble than they do now. NATs are something
> that need to be phased out as IPv6 is phased in, not something that need
> more support and encouragement from the architecture.

Right, but SRV records don't work with NATs anyway, unless they aren't 
indicating a new port (which is their intended use). The portnames 
solution would be NAT-friendly (if the NAT parsed the option).

> New RR types are what they are. Some are inevitably defined better than
> others. For the specific case of SRV, I don't think the RR was well
> defined. But DNS is not as extensible as we'd like, new RR types are
> scarce and difficult to deploy, and so there's some weight to the idea
> that we should make do with what we have whenever it doesn't break anything.

RIGHT!!!!!

Which is why using TXT records with SRVs - which is what most other SRV 
users do when they need OOB info - is the right way to go.

> I want to relax the requirements for domain names associated with SRV
> records. But the only reason I think that's okay is because I assume
> that existing DNS servers and client code doesn't enforce the syntax
> restrictions on domains associated with SRV records. (given various
> difficulties with rigidly enforcing such syntax, I think it's unlikely
> that existing code does that, though perhaps I'm wrong about that).

Do you really want to take that risk, rather than using TXT records 
which cannot be syntax-enforced anyway?

> Agree with that much. But "services as they're currently assigned by
> IANA" and that are reasonable to use with SRV are few, and a new RR is
> difficult to and time-consuming to deploy. This is a case where I think
> pragmatic reuse of SRV makes more sense than a purist approach.

Why then doesn't the pragmatic view include using TXT records the way 
other SRV users do?

I'm not being dogmatic at all here; I'm just applying the same kind of 
pragmatism to the most widely-deployed solution I'm aware (SRV + TXT).

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 15:30:45 -0700

On 9/12/2011 2:43 PM, Nico Williams wrote:
> On Mon, Sep 12, 2011 at 3:57 PM, Joe Touch<[email-masked]>  wrote:
>> My claim is that:
>>
> Existence proofs show that this is not *actually* so.

The existence proof is that many SRV names have defined TXT fields, 
including the following:
	ftp
	sftp-ssh
	ssh
	telnet
	http
	nfs (already defines path to the mount point)
	qttp (quicktime)
	webdav

 > It's only what RFC2782 was aiming for.
>
> Time has passed.  That ship has sailed.

Seems like that ship sails just fine.

There are bigger issues with widescale SRV use, but the use of 
associated TXT records isn't one of them as far as I've seen.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 15:42:08 -0700

On 9/12/2011 3:33 PM, Spencer Shepler wrote:
...
> Interesting; do you have a reference for that one?
>
> Spencer

http://dns-sd.org/ServiceTypes.html

The IANA service/ports registry is supposed to include everything here, 
but does not as yet (they're working on it).

Joe

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Sep 2011 18:49:17 -0400

On Sep 12, 2011, at 6:23 PM, Joe Touch wrote:

> Again I'm confused.
> 
> You claim there's a clear need to revise SRV syntax, but not the registry that basically defines that syntax?

I don't claim that there's a clear need to revise the syntax of the RDATA.  I claim that the syntax defined in RFC 2782 for the domains used with SRV RRs is relevant only when SRV is used as anticipated in RFC 2782... which is to say, almost never.

> If you don't need a generic mechanism with agility, just use TXT records and move on IMO. That's what most other SRV users *have already done*.

Given that I think service location is almost inherently application-specific anyway, that solution is also fine with me.  I don't know what value is added by SRV, other than confusion.

> If you insist on a clean, generic, system that solves this problem for nfsv4 domain-root and other similar cases, you're clearly arguing for the deep slog of fixing this throughout the IETF.

Eventually yes.   But I'm also arguing against holding up this document for reasons that seem to me to be pedantic.

> The worldwide default for services with assigned ports is to assume that port number.

yes.

> The worldwide system for doing otherwise is SRV records.

no.

> Either one works fine, and either one assumes that both sides make the same assumption.
> 

False.  SRV records are poorly designed and broken for several reasons already cited.  And SMTP is somewhat unique in that it doesn't make sense to think of it entirely in terms of pairwise connections.

> The only port that is difficult to change is the DNS. You need to *know* that for the host on which the DNS resides for the endpoints you want to contact before contacting them.

Using DNS to look up the port number opens Pandora's box and creates a great many opportunities for failure as well as encouraging pollution of the architecture.

> That "third party" could be at the same endpoint as the destination; in that case you'd be using that endpoint's DNS to bootstrap other services. Moving that capability to a separate location does compromise E2E, but the ability to remap ports has nothing to do with it per se.

In abstract theory, perhaps.  But in practice, you and I both know that there continues to be considerable pressure to impose additional layers of NAT and prolong use of IPv4. 

> Endpoints already can (and do) assume services on ports other than their IANA defaults, e.g. The point is that this is an endpoint decision, under control of the endpoints.

In many cases it's purely an endpoint decision.  Not all of them.

> I don't disagree; I would prefer port-names (for those not familiar, the idea was to use the IANA service names as a TCP option in the SYN packet, and to demux to the service based on that name string rather than the incoming port).

I identified several issues with port-names at the time you made that proposal.   One of the bigger problems IIRC was that they assumed that there could only be one service with a particular name on a particular host, when these days "virtual hosts" (by which I mean multiple services acting on behalf of different domains all supported by the same physical host) are quite common, and the notion of "host" has become fairly blurry.  I also think that IANA service names as currently defined are not a reasonable constraint to impose.  But in general I'd like to find a way to escape the 2^16 limitation on port numbers, and I think that that area deserves further study.

> We had this discussion recently elsewhere. You may not want that level of indirection when it doesn't do what you want, but others need that for other reasons (e.g., to push DNS through a firewall that hijacks it otherwise).

Sigh.   It needs to be understood that the existence of brain-damage in the network is not an inherent justification for adding more complexity.   There's a tussle between users and network administrators that exists because network administrators don't have good tools to do what they need to do, and also because they've developed mindshare around using poor tools and using them poorly.  But adding another level of indirection only makes this problem worse in the long run.

> Right, but SRV records don't work with NATs anyway, unless they aren't indicating a new port (which is their intended use). The portnames solution would be NAT-friendly (if the NAT parsed the option).

The NAT would just intercept port 43 traffic and translate the SRV record.  Then we'd have NAT polluting the DNS as much as it's polluting IP.

> Which is why using TXT records with SRVs - which is what most other SRV users do when they need OOB info - is the right way to go.

Nah, if you're going to use TXT records, don't bother with SRVs.  Avoid the extra lookup and the resulting hit in latency and reliability.  If DNS would reliably let you get both RR types in a single query, that would be fine, but it doesn't.

> Do you really want to take that risk, rather than using TXT records which cannot be syntax-enforced anyway?

Personally I think it's a reasonable risk.  But I don't think that mine (or yours) is the only opinion that should be taken into consideration.

> Why then doesn't the pragmatic view include using TXT records the way other SRV users do?
> 
> I'm not being dogmatic at all here; I'm just applying the same kind of pragmatism to the most widely-deployed solution I'm aware (SRV + TXT).

I just think it's a mess to do things that way.   And I see dubious benefit in propagating that mess.   IMO.

Keith

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Sep 2011 16:06:24 -0700

On 9/12/2011 3:49 PM, Keith Moore wrote:
> Given that I think service location is almost inherently
> application-specific anyway, that solution is also fine with me. I don't
> know what value is added by SRV, other than confusion.

SRV indicates the port number (useful if not the default) and weight, etc.

If that's not what you want, just use the corresponding TXT record, but 
include a field that indicates whether this is the correct record (e.g., 
domain-root).

>> If you insist on a clean, generic, system that solves this problem
>> for nfsv4 domain-root and other similar cases, you're clearly arguing
>> for the deep slog of fixing this throughout the IETF.
>
> Eventually yes. But I'm also arguing against holding up this
> documentfor reasons that seem to me to be pedantic.

All protocol specs are pedantic.

The way to avoid holding this doc up, IMO, is to use SRV records as 
they're currently used - with TXT records where additional info is needed.

...
>> The worldwide system for doing otherwise is SRV records.

I'll let Apple know.

> False. SRV records are poorly designed and broken for several
> reasonsalready cited. And SMTP is somewhat unique in that it doesn't
> make sense to think of it entirely in terms of pairwise connections.

What exactly isn't pairwise about mail relay?

> Using DNS to look up the port number opens Pandora's box and creates a great many opportunities for failure as well as encouraging pollution of the architecture.

Good. Then stop using SRV records. That's what they're for, in case it 
was at all vague in RFC 2782.

(NAT discussion omitted - NATs break SRV use anyway)

> I identified several issues with port-names at the time you made
> that
> proposal. One of the bigger problems IIRC was that they assumed that
> there could only be one service with a particular name on a particular
> host, when these days "virtual hosts" (by which I mean multiple services
> acting on behalf of different domains all supported by the same physical
> host) are quite common, and the notion of "host" has become fairly
> blurry.

Talk about breaking E2E. You are confusing a port with an endpoint ID.

...
...
> Nah, if you're going to use TXT records, don't bother with SRVs.  Avoid the extra lookup and the resulting hit in latency and reliability.

If you already know the port number, there's nothing that prevents you 
from doing this, FWIW.

 > If DNS would reliably let you get both RR types in a single query, 
that would be fine, but it doesn't.

So go fix *that*. ;-)

Joe

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Sep 2011 23:09:51 -0400

> SRV indicates the port number (useful if not the default) and weight, etc.

right.  but given that you can include the same things in a TXT record, if you have to query for TXT RRs anyway, what's the value added by doing an additional query for SRV RRs?

> All protocol specs are pedantic.

Perhaps, but their interpretations don't have to be pedantic.

> The way to avoid holding this doc up, IMO, is to use SRV records as they're currently used - with TXT records where additional info is needed.

Your notion of "currently" seems like a stretch.  My understanding is that they're currently used in several different ways, the RFC notwithstanding.

>>> The worldwide system for doing otherwise is SRV records.

Thanks.  :)

> What exactly isn't pairwise about mail relay?

Right now, if you want to be able to receive mail reliably, you have to have an MX which listens on port 25.  If you want to send mail across administrative boundaries, in general, you have to be able to send to port 25.  There's no way to do pairwise port negotiation.

Of course, in some hypothetical other world with a slightly different mail protocol, the problem could be solved differently.

> Good. Then stop using SRV records. That's what they're for, in case it was at all vague in RFC 2782.

I'd be very happy to see SRV records deprecated, or at least discouraged, for new protocols.

> Talk about breaking E2E. You are confusing a port with an endpoint ID.

You might have an easier time understanding what I'm saying, if you weren't so busy trying to prove to yourself that I'm confused.

> If you already know the port number, there's nothing that prevents you from doing this, FWIW.

Or if you really need to support arbitrary ports, just encode the port number in the TXT record.

> > If DNS would reliably let you get both RR types in a single query, that would be fine, but it doesn't.
> 
> So go fix *that*. ;-)

If I were going to fix DNS, that would be only one of several things on my list of things to fix.  But I don't think the Internet is desperate enough to want to fix DNS yet.

Keith

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Sep 2011 08:38:20 -0600

On Sep 12, 2011, at 1:00 PM, Robert Thurlow wrote:

>> If it is, then it should be using _nfs._tcp.example.com, etc. If it isn't, then:
> We don't want to enumerate all NFS servers in a domain.  That is
> Rob T

Hi Rob, 

Few inputs you can take with a huge grain of salt

1) some people on this list have suggest TXT records. Keep in mind this is totally the wrong group to tell you how to use DNS. Last time I discussed TXT records with the DNS directorate they certainly would not have recommended them for this use. I suspect the advice to use TXT is very bad but either way, if you want advice on that, go talk to the DNS Directorate not the transport guys. 

2) My understanding is that you have two types of service you want to be able to find using SRV. Now these two services both happen to use the same protocol to talk to them and both run on same default port so you don't need two ports allocated for them but you do need to be able to make separate DNS entries for the two because some servers offer one of the service and some don't. 

Using SRV and having one labels like _service1._tcp.example.com for one service and _service._tcp.example.com for the other service seem perfectly reasonable to me, but this is the TSV review and I don't know why the TSV directorate would be providing any comment on how you use DNS. Now the fact that both will likely point as the same port and same server in some times seems fine to me. 

3) Nothing to do with TSV but, your motivation for separating the _service1._tcp into _service1._foo._tcp seems like something you don't really need and is going to make this  harder for you to get this all approved. Unless you need this, I'd think carefully about how much you want it. Keep in mind if some other protocol wants the domain concept, they can just go allocate two tags for use in SRV DNS.

4) I have not seen a single transport issue raised in this thread 

Cullen

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 Sep 2011 08:20:05 -0700

Hi, Nico,

On Sep 12, 2011, at 5:56 PM, Nico Williams <[email-masked]> wrote:

> On Mon, Sep 12, 2011 at 5:30 PM, Joe Touch <[email-masked]> wrote:
> I meant existence as in "how it's used".  I don't see why
> Windows/AD/Samba/... can use SRV RRs the smart way while the rest of
> us must not.  That would be silly.  It's not our fault that RFC2782 is
> outdated.  Nor is it our job to update it.

The Windows examples explain their use as basically a naming convention for servers, where they 
	a) add a few prefixes to the FQDN
	b) some of which violate DNS specs
	c) where the FQDN doesn't match the hostname

i.e., they add foo._bar.nsf.example.net when they intend a FQDN of nsf.example.net

There are three problems with that - which could interfere with other interpretations of those SRV records (e.g., tools that might scan those records to monitor service liveness). 

> But, let's see if we can change the direction of this thread (we're
> going in circles).
> 
> Would you oppose an update to RFC2782 to standardize different SRV
> RRset _name_ conventions?

I would, as per above. That would be pushing context-dependent syntax into the SRV record rather than using a separate RR - where that syntax belongs. Note that SRVs changed DNS RRset name conventions but only for the SRV RR. I.e., the precedent is that changing the syntax requires a new RR.

> If not, are you aware of any others who might?
> 
> If you don't object, who should be responsible for making the update,
> keeping in mind that these alternative SRV RRset naming conventions
> shipped long ago?

There are plenty of cases of protocols and extensions that are deployed that don't meet spec.

If we should take a cue from deployed code, we should (IMO) follow Apple not Microsoft in this case.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 Sep 2011 08:25:28 -0700

On Sep 12, 2011, at 8:09 PM, Keith Moore <[email-masked]> wrote:
...
...
...
> But I don't think the Internet is desperate enough to want to fix DNS yet.

I conclude from this sequence that you would prefer to reinvent the DNS inside TXT records (which is possible, but fruitless), and that others do this on your behalf.

This is outside the focus of this thread.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 Sep 2011 08:27:56 -0700

Hi, Craig,

On Sep 13, 2011, at 5:58 AM, "Everhart, Craig" <[email-masked]> wrote:

> Hi,
> 
> Thanks, Joe, for the thoughtful review.
> 
> Extracting some light from yesterday's discussion and RFCs 6335 and
> 2782, much of the contention seems to be around whether there could be
> two assigned names for related services that both happen to be provided
> over a given assigned port number.
> 
> I'd like to propose an adjustment of the request, in light of the RFC
> text, and ask your judgment on how that adjusted request would fit
> within the services rubric that's outlined.
> 
> In RFC 6335, explicit room is carved out for "assigned service name[s]
> without [a] corresponding fixed port number" with explicit reference to
> RFC 2782.  Such a service name assignment would be completely adequate
> for purposes of the "NFS domain root" concept.  As I read RFC 6335, such
> assignments are RECOMMENDED, and that IANA strives to assign such names
> under a first-come first-served policy (with reference to RFC 5226).
> 
> In this formulation, the existing "nfs" service could stand unaffected.
> The proposed service, "nfsdomainroot", would request name assignment
> without a port number.  The NFS client would seek SRV records under
> names such as "_nfsdomainroot._tcp.example.com".  The result processing
> would continue as before, with SRV records indicating the hosts
> providing NFS service for the root of "example.com"'s file system.
> 
> The SRV record then includes the port number on which the target NFS
> hosts provide "nfsdomainroot" service, which is given as an application
> of the NFS protocol in the subject I-D (including a mount point).
> 
> The I-D would also need to propose, in the IANA section, that IANA
> assign the service name
>    SRV    nfsdomainroot    TCP
> to this protocol.  UDP service name allocation is unnecessary.
> 
> In the judgment of the TSVDIR, would this take the I-D in a more
> acceptable direction?

There is one caveat: if you indicate the current NFS port in this SRV, and then validate it somehow, you should be OK with "nsf" as the response.

I.e., port numbers have exactly one canonical name, and no aliases. This should be made clear in the doc.

Otherwise, this seems viable AFAICT.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 Sep 2011 08:35:23 -0700

> 1) some people on this list have suggest TXT records. Keep in mind this is totally the wrong group to tell you how to use DNS. Last time I discussed TXT records with the DNS directorate they certai…

Agreed, however the point that TXT records are currently used this way can be part of the decision of how to approach the issue.

> Using SRV and having one labels like _service1._tcp.example.com for one service and _service._tcp.example.com for the other service seem perfectly reasonable to me, but this is the TSV review and I…

RFC 6335 is a TSV document, and the TSV area oversees IANA service and port assignments. I agree that this is not solely the purvue of TSV, though.

> 3) Nothing to do with TSV but, your motivation for separating the _service1._tcp into _service1._foo._tcp seems like something you don't really need and is going to make this  harder for you to get…

Agreed. This is the current approach being documented in TSV area for consideration (though not yet widely discussed).

> 4) I have not seen a single transport issue raised in this thread 

Please review *your own* posts from Feb of this past year, where you will find the precursor to RFC 6335 named "draft-ietf-tsvwg-".

JOe

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Sep 2011 10:03:29 -0500

to this:

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Sep 2011 12:49:07 -0500

Nico
--

---

From: Robert Thurlow <[email-masked]>
Date: Mon, 12 Sep 2011 13:00:50 -0600

Rob T

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Sep 2011 15:00:03 -0500

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Sep 2011 15:17:42 -0500

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Sep 2011 15:23:34 -0500

Nico
-- 

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Sep 2011 16:43:02 -0500

>        expressible in the IANA service/port registry

Existence proofs show that this is not *actually* so.  It's only what
RFC2782 was aiming for.

Someone should update RFC2782 for the benefit of the community, but I
don't see how that could be a requirement here.  Much less do I think
anything could preclude such an update.

Nico
--

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 12 Sep 2011 22:33:45 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joe Touch
> Sent: Monday, September 12, 2011 3:31 PM
> To: Nico Williams
> Cc: [email-masked]; draft-ietf-nfsv4-federated-dns-srv-
> [email-masked]; [email-masked]; [email-masked]; tsv-
> [email-masked]; Keith Moore
> Subject: Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-
> namespace
> 
> 
> 

Spencer

> There are bigger issues with widescale SRV use, but the use of associated
> TXT records isn't one of them as far as I've seen.
> 
> Joe
> 
> 
> 
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 12 Sep 2011 22:48:14 +0000

> From: Joe Touch [mailto:[email-masked]]
> Sent: Monday, September 12, 2011 3:42 PM
> To: Spencer Shepler
> Cc: Nico Williams; [email-masked]; draft-ietf-nfsv4-federated-dns-srv-

That entry is wishful thinking at best and wholly unspecified in anything
that I have ever seen and certainly not implemented (to my knowledge).

Spencer

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Sep 2011 19:56:29 -0500

Nico
--

---

From: "Everhart, Craig" <[email-masked]>
Date: Tue, 13 Sep 2011 08:58:47 -0400

Hi,

		Craig

> Sent: Sunday, September 11, 2011 4:12 PM
> To: [email-masked]; tsv-
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [nfsv4] TSVDIR review ofdraft-ietf-nfsv4-federated-dns-srv-
> namespace
> 
> Hi, all,
> 
> I've reviewed this document as part of the transport area
directorate's
> ongoing effort to review key IETF documents. These comments were
> written primarily for the transport area directors, but are copied to
> the document's authors for their information and to allow them to
> address any issues raised. The authors should consider this review
> together with any other last-call comments they receive. Please always
> CC [email-masked] if you reply to or forward this review.
> 
> This document describes the use of DNS SRV records to coordinate NFS4
> use and a global file namespace across a groups of clients and
servers.
> 
> There are no transport protocol issues in this document. The key
> transport issue is the definition of a new DNS SRV record and its
> associated syntax.
> 
> There are issues with the intended syntax of the proposed DNS SRV
> record. The current syntax is defined in RFC 2782 as:
> 
> 	_service._transport.NAME
> 
> 	service is an IANA SRV name, the namespace of which is defined
in
> RFC 6335
> All other information specific to the exchange, e.g., organization
> (which may or may not be a suffix of the Target, FWIW), desired mount
> point, and various NFS-specific capabilities (e.g., mount options)
> ought to be expressed in an associated TXT record as defined fields,
as
> is the case with other services that use SRV records. These options
can
> have defaults if not otherwise present.
> 
> Overall, the above is the key concern, and needs to be addressed
before
> proceeding. Issues below are indicated as either critical or
> suggestions for clarification.
> 
> Joe
> 
> ------------------------
> 
> Critical issues:
> 
> It is not clear whether an additional assignment of "SRV nfs SCTP" is
> required; recent discussions on other SCTP SRV uses suggest that UDP
is
> indexed in these cases instead. This might warrant further discussion.
> 
> The DNS request should return all available options, and indicate
write
> vs. read-only in the associated TXT records. The client should then
> determine which is desired.
> 
> ----------------------
> 
> Throughout this document, "version 4" is used wherever NFS is used.
> Since V4 (more specifically, 4.1) is the current common version, it
> does not seem necessary to include this marking in most places except
> where differences in the NFS versions are being highlighted.
> 
> - colloquial advice
> Terms like "appropriate" and "useful" should be removed throughout.
> They represent judgements whose evaluation criteria is not discussed.
> 
> - overall writing style
> The document is written in the tense and style of a proposal. It
should
> be revised to read as the intended specification it will become. "We
> propose" and "We use", and similar styles should be replaced with
"this
> document specifies" and "this record uses".
> 
> Terms like "root" and "name space" are widely used in different ways
in
> the DNS and file systems. Because this document combines the two, each
> use should be clarified by a preceding term, e.g., DNS name space or
> file system name space, DNS root or file system root.
> 
> In particular, SHOULD should be used only where a specific exception
is
> currently known or suspected, and that exception described. This
> provides the motivation for the selection of SHOULD vs. MAY or MUST.
> 
> - the discussion of client vs server implementation (sec 4.3, as well
> as partly in sec 4.2) should consider client-specific DNS responses
> The DNS could provide responses that vary based on the IP of the
client.
> This could be a desirable feature. Further, the client knows whether
it
> wants write or read-write copies. AFAICT, the client is not only the
> better place to implement this capability, it is the only viable
place.
> It does not make sense to overload read-only with directory
visibility;
> these are orthogonal issues. The desired mount point should be
> indicated in the TXT record; if a default convention is desired, it
> should be indicated in the description of that field.
> 
> Not sure which particular reference is best, but a permanent reference
> would be useful, e.g.: Matthew Crosby. 1997. AMD-AutoMount Daemon.
> Linux J. 1997, 35es, Article 4 (March 1997).
> 
> -----
> 
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 13 Sep 2011 12:10:23 -0400

> This is outside the focus of this thread.

Again, Joe, you're really bad at trying to discern my motives.  I suggest you reread what I've written and take it at face value.

Keith

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Sep 2011 11:55:58 -0600

Craig, 

I can't see how the transport directorate is relevant given there are no transport issues involved but ignoring that, as an individual contributor at the IETF, what you are proposing below looks like a simple and easy path forward that would work fine. 

Thought I agree that RFC 2782 needs and update, preferable done by Stuart Cheshire, to bring it in line with what is widely deployed, I am pretty confident that updating 2782 will not be a quick or easy process. 

Cullen

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 14 Sep 2011 05:56:30 +0900

Keith Moore wrote:

> Why use SRV records at all if you also need TXT records to convey
> part of the information needed by apps (and thus, have to
> do multiple queries for the same level of information)?  Why not
> just encode all of the information in TXT records?

I fully agree with you.

					Masataka Ohta

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Sep 2011 13:01:47 -0500

> i.e., they add foo._bar.nsf.example.net when they intend a FQDN of nsf.example.net

They have prefixes for domainnames, yes (of course FQDN), where the
domainnames do not correspond to hosts, but to what we colloquially
refer to as "domains".

All of the most important of these SRV RR uses in Windows use RRset
naming conventions that differ from those in RFC2782.  There are many
implementations of this (I know of at least four in the *nix space,
probably more if we include proprietary scripts written using Perl5,
Python, ..., that must abound in corporate land).  And of course,
there's Widnows'.  I know of at least three server-side
implementations (though, of course, the DNS server component itself
requires no special sauce in order to support any of this, as DNS
servers do not encode RRset naming conventions like RFC2782's).

> There are three problems with that - which could interfere with other interpretations of those SRV records (e.g., tools that might scan those records to monitor service liveness).

Nonsense.  This stuff exists and has been deployed for over a decade.
I've never heard of a tool choking on these SRV RRsets.  If you have,
please list them and explain why anyone should care that there exist
tools which cannot cope with a widely deployed system like this.

> I would, as per above. That would be pushing context-dependent syntax into the SRV record rather than using a separate RR - where that syntax belongs. Note that SRVs changed DNS RRset name conventi…

Then there's no point continuing this discussion without participation
from IESG members.

The I-D authors will have to negotiate without my participation.  I
recommend continuing the process until the IESG balks, if they do.  If
the IESG balks, then appeal.

Nico
--