Subject: [nfsv4] [FedFS] meeting agenda (9/10)

From: James Lentini <[email-masked]>
Date: Wed, 9 Sep 2009 16:29:20 -0400 (EDT)

Tomorrow's proposed agenda is below. Please let me know if you would 
like to add anything.

    Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST
 Dial-in: 1-888-765-3653 (us)
          303-218-2659 (international)
      Id: 2354843

Proposed Agenda
---------------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each week's meeting with this announcement.

+ Review Action Items

  - James Lentini find out who is attending Bake-a-thon from NetApp.

  - James Lentini will draft text describing the format of the fedfsNfsPath

+ Austin NFS Bake-a-thon

+ NSDB Draft Update

  Review updated NSDB draft:

  http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-protocol-03bis.txt

  A diff with the published draft is here:

  http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-protocol-rfcdiff.html

  This update includes the changes we've been discussing on the mailing 
  list and at our weekly meetings, including:

  - Reference DNS SRV document
  - Clarify LDAP user configuration (Section 4.1)
  - Updated fedfsNfsPathname to use pathname4 encoding
  - Expand descriptions to include example values (Section 5)
  - Add missing LDAP OID registration field.

+ Discuss Feedback on LDAP Configuration

---

From: Daniel Ellard <[email-masked]>
Date: Thu, 10 Sep 2009 11:54:24 -0400

Due to a weekly customer meeting (which I have no
say in scheduling) it looks like it will be difficult for me
to attend the weekly fed-fs conference calls for the
next month (possibly several).  I might be able to dial
in late.

I know it's very difficult to coordinate schedules with so
many different people, but if the topic comes up, I would
be open to rescheduling the fed-fs calls, or perhaps having
them at alternating dates/times (so maybe I could make
one every second week, if not every week).

Thanks,
    -Dan

On Wed, Sep 9, 2009 at 4:29 PM, James Lentini <[email-masked]> wrote:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Sep 2009 13:44:46 -0500

>           303-218-2659 (international)

My meetings ran late.  Sorry.

However, after talking about this Rob Thurlow and Leif Johansson, a) I
understand why junctions are not modeled in the NSDB, b) I understand
that objects in the NSDB are created and forgotten -- the NSDB can be
full of garbage and that's OK (well, controls on rate of resource
consumption may be desirable?).  Leif also argues that it's very likely
that no one will want to deploy the NSDB on existing directory
infrastructures -- I'm not convinced, but I'm convinced it's not a big
deal if they can't.

That means that most of my concerns are now minor.

 - If you add an NSDB base DN to FSNs and junctions, then you can allow
   customers to deploy the NSDB on existing infrastructures.

   Junctions are of the form {FSN UUID, NSDB name}, where the NSDB name
   is variable size but can be interned to get a fixed sized object.
   Storing the NSDB base DN, either in the junction or interned along
   with the NSDB name should be fine.

   It seems that allowing the use of existing infrastructure should be
   easy -- just add a logical attribute storing the NSDB base DN to
   junctions and FSNs.

   Leif convinces me that this is desirable, but also not quite so
   important.  If you think that allowing for alternate base DNs is too
   large a burden then I'll likely yield.

 - Using names instead of UUIDs would require storing object DNs or RDNs
   in junctions -- that's not as easy to compress into a fixed-sized
   object for referencing from junctions stored in filesystems.

   Therefore I agree that using UUIDs is very desirable, and yield.

 - I think using an all-textual encoding of path names would go a long
   way to making it possible to use off-the-shelf LDAP tools/UIs to
   manage NSDB data.  So I strongly recommend defining one (or more)
   path component separator characters, one escape character, and an
   escaping sequence for the escape and path separator characters.

Comments?

Nico
--

---

From: James Lentini <[email-masked]>
Date: Thu, 10 Sep 2009 15:38:04 -0400 (EDT)

> My meetings ran late.  Sorry.

That's ok. In your absence we assigned you an action item to write up 
your proposed changes. This email satisfies that request.

>    large a burden then I'll likely yield.

So your proposal is to change the FSN definition from

 {FSN UUID, NSDB name}

to 

 {FSN UUID, NSDB name, base DN}

is that correct?

While the base DN can be of arbitrary size, in practice I believe we 
can expect them to be quite short. Do you agree?

>    escaping sequence for the escape and path separator characters.

Rob shared this with us at the meeting. We discussed some possible 
ideas. I have an action item to come up with a way a specific 
recommendation. If you have a specific proposal in mind, please let us 
know.

Thanks,
-james

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Sep 2009 14:49:54 -0500

> your proposed changes. This email satisfies that request.

OK.

>  {FSN UUID, NSDB name, base DN}

Yes.

> can expect them to be quite short. Do you agree?

The same is true of NSDB name.  Yes.

Oh, I forgot to mention something else that Rob and I discussed.  NSDB
name is the sort of thing one would want to resolve via DNS SRV RRs
(prepend _nsdb._ldap._tcp to the name, resolve to SRV RRs, resolve to
the resulting names to IP addresses, order by weight/priority and
random).

> recommendation. If you have a specific proposal in mind, please let us 

My proposals, in order of preference:

1) Use '/' and '\' as path component separators, use HTML-like entities
   to escape them: &slash; &backslash; and &amp;.

   Allowing the use of both common separator characters will be friendly
   to users from all backgrounds.  HTML entities are well-known nowadays
   by most users who would be NSDB admins.

2) Use '/' and '\' as path component separators, and '*' as an escape
   character with these escape sequences:  */, *\, **.

   '*' should, I think, make a good escape character because of its near
   universal role as a glob character, which means it's very unlikely to
   appear in actual file/directory names.  And it's printable (compare
   to ESC [033]).  Alternative escape charaters are possible, of course:
   '^', '`', ''', ...

3) Same as proposal either 1 or 2, but with only one separator
   character, '/', which would allow '\' to be the escape character.

   This would be friendly to users who have a Unix background, but not
   so friendly to users from a Windows background.

Nico
--

---

From: James Lentini <[email-masked]>
Date: Fri, 11 Sep 2009 12:04:18 -0400 (EDT)

> The same is true of NSDB name.  Yes.

An NDSB name is either an IPv4, IPv6, or DNS name. All of those have a 
maximum size. In particular a DNS name is limited to 255 total 
characters (see Section 3.1 of RFC 1034):

 To simplify implementations, the total number of octets that represent a 
 domain name (i.e., the sum of all label octets and label lengths) is 
 limited to 255.

Adding an FSN field of arbitrary size is probably ok, but we should 
carefully think through the consequences. 

I would suggest that the specification require implementations to 
accept a DN of size X and allow them to accept larger sizes. Something 
like:

 A fileserver MUST accept a DN of length 512 octets (including the 
 terminating NULL character) and MAY accept a larger DN.

On a different subject, would this DN be the base suffix of the NSDB's 
LDAP DIT or the DN of the entry containing the FedFS entries. For 
example, if the NSDB's base suffix was "dc=example,dc=com" and the 
administrator had created an entry "ou=fedfs,dc=example,dc=com" below 
which the FedFS FSNs and FSLs were stored, should the DN stored in an 
FSN be "dc=example,dc=com" or "ou=fedfs,dc=example,dc=com"? I would 
assume the later.

> the resulting names to IP addresses, order by weight/priority and

Oh yes. Thank you for bringing this up.

I have reservations about using SRV RRs for this. The advantages of 
using SRV RRs are not clear to me, but I can think of two 
disadvantages.

First, the IETF does not appear to have standardized a mechanism for 
locating LDAP directories using SRV RRs. As I mentioned previously, 
draft-ietf-ldapext-locate expired long ago and the work on this 
appears to have halted. I liked to understand if there was some 
technical reason for that.

Secondly, I'm unclear on the technical benefits of locating the NSDB 
via an SRV RR. It prevents more than one NSDB to be deployed in a 
domain while the current system allows for multiple NSDBs per domain. 
Also it adds another step (and network round trip) to the process a 
fileserver must go through to resolve a junction. I'm concerned about 
the performance implications of that.

The vision has been that NSDB host names may resolve to multiple IPs 
for load balancing and high availability.

>    to ESC [033]).  Alternative escape charaters are possible, of course:

The idea of allowing multiple path component separators is very 
interesting. I like being friendly to all users. Personally, proposal 
#2 appeals to me the most.

One question that came up during the meeting yesterday was how to deal 
with path names such as 

 C:\path\to\somewhere

Would the ":" be included in the string? There was discussion about 
whether this was even a legal network pathname, but I don't think we 
came to a firm conclusion on that.

Another was how to deal with VMS pathnames that also use multiple 
different path component separators.

-james

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Sep 2009 11:57:36 -0500

>  terminating NULL character) and MAY accept a larger DN.

Sure.  I'd be fine with limiting the base DN even further (say, 320
bytes).  Also, on the plus side, if you're storing base DN and your
local [non-NSDB] directory infrastructure knows how to issue referrals
for objects beneath that DN, then you don't need to store the NSDB name.

Incidentally I hadn't realized that you were counting on them being
fixed sized until very recvently.  In fact, the whole notion of keeping
the FSNs small and fixed sized eluded me completely until about 40 hours
ago -- it seems like a central aspect of the project, dictating a number
of design details, yet the requirements document doesn't even mention it!

Once I did I figured implementors would be interning the common[*],
variable length parts (NSDB name) to keep the total size of FSNs down
and fixed.  Now I see that you were counting on the maximum size of
variable sized parts of FSN references to be small enough.  The desire
to have small, fixed-sized FSN references should really be called out
very early on, possibly even in the abstract, in the I-Ds.

[*] There's no point in interning the part that is different in ever
case, namely UUIDs.

> FSN be "dc=example,dc=com" or "ou=fedfs,dc=example,dc=com"? I would 

If we demand that o=fedfs always be present, then it wouldn't need to be
in the stored base DN.

> using SRV RRs are not clear to me, but I can think of two 

ISTM that "clustered" services (I'm not sure what the word is to use
here) are best represented as SRV RRs.

> technical reason for that.

I'm not sure that LDAP location is relevant.

> domain while the current system allows for multiple NSDBs per domain. 

Is that so?  I thought you'd prefix something like "_nsdb._ldap._tcp."
to the NSDB name and then look that up.  I didn't think that the NSDB
name would be a domain name such as "sun.com".

> the performance implications of that.

Yes, it does do that.  But presumably there will be relatively few,
often-referenced NSDB names, so caching, and proactive lookups can make
this problem go away.  In any case, the need to do blocking DNS lookups
is already there.

> for load balancing and high availability.

Rob explained as much to me.

> came to a firm conclusion on that.

Windows NFSv4 servers surely have to do something about drive letters.
Whatever a server's implementor chose to do w.r.t. drive letter names is
what the user should do here as well.  (Path names enter the picture in
the FSLs, which reference a specific server each.)

> different path component separators.

I don't remember VMS very well.  Perhaps you could adjust my proposals
to serve VMS users as well?

Nico
--

---

From: James Lentini <[email-masked]>
Date: Fri, 11 Sep 2009 16:03:03 -0400 (EDT)

> for objects beneath that DN, then you don't need to store the NSDB name.

The name of the local directory would need to be stored though or are 
you assume that a DNS SRV record would be consulted for that?

> of design details, yet the requirements document doesn't even mention it!

I wouldn't describe this as a central requirement, but limiting the 
maximum sized of an FSN does simplify implementations. The FSNs need 
to be saved to durable storage. Objects with a maximum size make that 
task easier.

> very early on, possibly even in the abstract, in the I-Ds.

Good point. This property of an FSN should noted in the specification. 
I'll add that in the next version.

> If we demand that o=fedfs always be present, then it wouldn't need to be

If an FSN stores a DN, do we need to demand o=fedfs be present? Below 
the entry identified by the FSN's DN, we could simply require the 
structure described today (FSN entries with FSL children).

> I'm not sure that LDAP location is relevant.

So this would be an NSDB record, not an LDAP record? 

In that case, the lookup would be for:

 _nsdb._tcp.example.com 

Correct?

A draft describing DNS SRV RR for NSDBs would need to be written, but 
we can do that. 

I'll do some research on the LDAP SRV RR format to see if there were 
any technical issues that derailed it.

> name would be a domain name such as "sun.com".

See above for the format of the lookup value I would expect.
 
> this problem go away.  In any case, the need to do blocking DNS lookups

The need to do at most 1 DNS lookup is there today. An NSDB name may 
be an IPv4, IPv6, or DNS name. If it is a DNS name, then there will 
need to be a DNS lookup.

If a DNS SRV record stores the NSDB name, then at most 2 DNS lookups 
are necessary: one to obtain the RR and one to resolve the DNS name in 
the RR.

As you say, caching and proactive lookups may mitigate this issue 
entirely.

> to serve VMS users as well?

I don't remember VMS at all. :)

At the meeting yesterday, I took an action item to run through the 
possible formatting options with Trond before next week's meeting. 
I'll lean on his knowledge of VMS and other exotic pathnames and 
report back.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Sep 2009 15:20:49 -0500

> you assume that a DNS SRV record would be consulted for that?

The latter.  Obviously if there's no such thing as "the local directory"
and the local NSDB itself can't generate the referral, then yes, you'd
need to store the NSDB name.  I see your point: figuring out when you
could store the base DN but not the NSDB name is complex.

> to be saved to durable storage. Objects with a maximum size make that 

To me it's practically a central requirement, and it explains a number
of design points that I could not otherwise understand.  Put it this
way: if I'd known about this requirement from the get-go then these
threads could have been much shorter :)

> structure described today (FSN entries with FSL children).

I think so.  The reason is that directories are required to enforce RDN
uniqueness within each container, but since we don't want to store
random bits of an object's full DN -- just the UUID and base DN -- we
lose that uniqueness requirement.  By segregating all NSDB objects into
a single container we get it back.

(Thus the desire for small fixed identifiers leads to the o=fedfs
container, scope=one and the use of UUIDs.  All features that I could
not at first understand.)

Yes.

> In that case, the lookup would be for:

Yes, except that I don't see why it couldn't be
_nsdb._tcp.nsdb-one.example.com, and _nsdb._tcp.nsdb-two.example.com,
supposing that example.com has two distinct NSDBs.

> A draft describing DNS SRV RR for NSDBs would need to be written, but 

I don't feel too strongly about this.  The DNS directorate might.  So
consider this a heads up more than anything.

> any technical issues that derailed it.

I should too...

> are necessary: one to obtain the RR and one to resolve the DNS name in 

The need for any lookups at all is the main issue.  Once you accept
that, N lookups is no worse, implementation-wise, than 1.  N lookups
does mean more latency, but that's probably not a big deal in this
context.

> As you say, caching and proactive lookups may mitigate this issue 

Specifically proactively keeping cached items valid, by re-doing lookups
ahead of TTL-driven cache expiry.

> I don't remember VMS at all. :)

Making effective use of limited human memory, I see :)

OK.

Nico
--

---

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 11 Sep 2009 16:55:57 -0400

One nit: 
> From: Nicolas Williams [mailto:[email-masked]] 
..
> > > > First, the IETF does not appear to have standardized a 
> mechanism 
> > > > for locating LDAP directories using SRV RRs. As I mentioned 
> > > > previously, draft-ietf-ldapext-locate expired long ago and the 
> > > > work on this appears to have halted. I liked to understand if 
> > > > there was some technical reason for that.
> > > 
> _nsdb._tcp.nsdb-one.example.com, and 
> _nsdb._tcp.nsdb-two.example.com, supposing that example.com 
> has two distinct NSDBs.

But you'd still look up some single name, e.g.
	_nsdb._tcp.example.com
and then the result would have two RRs, one for nsdb-one and one for
nsdb-two, right?  Or are you thinking of putting "nsdb-one.example.com"
in the FSN?

Either way would work, but they mean two different things.  In the first
case, there are two servers (or at least domain names with addresses)
providing interchangeable service.  In the alternative case, and maybe
it's the one you started with, the organization responsible for a domain
name provides two NSDBs that each offer service for a distinct
(sub-)domain.

		Craig

> I don't feel too strongly about this.  The DNS directorate 
> might.  So consider this a heads up more than anything.
>

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Sep 2009 15:55:34 -0500

> nsdb-two, right?  Or are you thinking of putting "nsdb-one.example.com"

No, I was saying that the SRV RR name to look up is "_nsdb._tcp." + NSDB
name.  I don't see why NSDB name must be a "domain" and only a domain.

Nico
--

---

From: James Lentini <[email-masked]>
Date: Sun, 13 Sep 2009 18:28:21 -0400 (EDT)

On Fri, 11 Sep 2009, Nicolas Williams wrote:

> No, I was saying that the SRV RR name to look up is "_nsdb._tcp." + 
> NSDB name. I don't see why NSDB name must be a "domain" and only a 
> domain.

RFC 2782 defines the SRV RR's name field to be a domain. 

A fileserver named foo.example.com isn't part of the 
nsdb-one.example.com domain and doesn't know if such a domain exists, 
so it wouldn't lookup an SRV RR for "_nsdb._tcp.nsdb-one.example.com".

The functionality you're suggesting is available with other DNS 
mechanisms.

A DNS alias may be used to provide a level of indirection between the 
FSN's NSDB name and a particular hostname (e.g. "ndsb.example.com" 
might be aliased to "nsdb56a.example.com") and multiple DNS address 
records can be used for high availability (e.g. "nsdb56.example.com" 
may have 3 IP addresses).

For these reasons, the specification allows the NSDB name to be 
recorded as a hostname.

-james

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Sep 2009 00:04:20 -0500

> RFC 2782 defines the SRV RR's name field to be a domain. 

And it says that there "domain" is strictly in the RFC1034 sense.  What
that means exactly we should ask of a DNS expert, but my own reading of
these RFCs and experience says that "domain" in the RFC1034 sense is not
in the "administrative domain" sense, nor in the "a domain name for
which there is an SOA RR", or even in the "a name below which there
exist other names" (and why should there be any names below the Name of
an SRV RR?).  Here "domain" really seems to mean "domain name".

> For these reasons, the specification allows the NSDB name to be 

IMO we should ask the DNS directorate.

Nico
--

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 14 Sep 2009 09:55:33 -0400

> -----Original Message-----
> From: Lentini, James 
> Sent: Sunday, September 13, 2009 6:28 PM
> To: Nicolas Williams
> Cc: Everhart, Craig; Lentini, James; [email-masked]
> Subject: Re: [nfsv4] [FedFS] meeting agenda (9/10)
> 
> 
> 
> > > > _nsdb._tcp.nsdb-two.example.com, supposing that example.com has 
> > > > two distinct NSDBs.
> > > 

As I understand it, there's no distinction between the name of a
"domain" vs. the name of a host or any other DNS-formatted name, as far
as SRV goes.  So I don't understand Nico's objection.
 
> nsdb-one.example.com domain and doesn't know if such a domain 
> exists, so it wouldn't lookup an SRV RR for 
> "_nsdb._tcp.nsdb-one.example.com".

It would if the foo.example.com file server were told to use
"nsdb-one.example.com" as the NSDB referent in a junction.
 
> The functionality you're suggesting is available with other 
> DNS mechanisms.
> 
> A DNS alias may be used to provide a level of indirection 
> between the FSN's NSDB name and a particular hostname (e.g. 
> "ndsb.example.com" 
> might be aliased to "nsdb56a.example.com") and multiple DNS 
> address records can be used for high availability (e.g. 
> "nsdb56.example.com" 
> For these reasons, the specification allows the NSDB name to 
> be recorded as a hostname.
> 
> -james
> 

		Craig

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 14 Sep 2009 09:56:55 -0400

Oops, I didn't read ahead in my mail--I'm agreeing with Nico.

		Craig 

> Sent: Monday, September 14, 2009 1:04 AM
> To: Lentini, James
> Cc: Lentini, James; [email-masked]
> And it says that there "domain" is strictly in the RFC1034 
> sense.  What that means exactly we should ask of a DNS 
> expert, but my own reading of these RFCs and experience says 
> that "domain" in the RFC1034 sense is not in the 
> "administrative domain" sense, nor in the "a domain name for 
> which there is an SOA RR", or even in the "a name below which 
> there exist other names" (and why should there be any names 
> below the Name of an SRV RR?).  Here "domain" really seems to 
> mean "domain name".
>

---

From: James Lentini <[email-masked]>
Date: Mon, 14 Sep 2009 10:02:35 -0400 (EDT)

> IMO we should ask the DNS directorate.

I'll ask the DNS directorate to clarify if the Name field of a SRV RR 
may contain a hostname.

Regardless of that, there does not appear to be any advantage to using 
SRV RRs. 

An FSN is defined as:

 <nsdb_hostname, ldap_base_dn, uuid>

A fileserver will use DNS to resolve the nsdb_hostname. For that, 
we've been discussing these two alternative:

 (a) resolve nsdb_hostname to one or more IP addresses using alias and 
     address records.

 (b) lookup the SRV RR for nsdb_hostname and obtain one or more target 
     hostnames. Then resolve the target hostnames to one or more IP 
     addresses.

In (b) there is an extra step but no functional benefit. As we've 
discussed, prefetching and caching of these lookups may be used to 
mitigate any performance issues. This is true for both options with 
(a) requiring fewer lookups and hence less items to cache.

-james

---

From: James Lentini <[email-masked]>
Date: Mon, 14 Sep 2009 10:12:08 -0400 (EDT)

Perhaps I've read to much into RFC 2782's use of "domain" versus 
"domain name". I've asked the DNS directorate to clarify. In any 
event, I don't see any advantage to using SRV RRs for this purpose. 
What am I missing?

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 14 Sep 2009 10:14:04 -0400

> Sent: Monday, September 14, 2009 10:03 AM
> To: Nicolas Williams
> > > > No, I was saying that the SRV RR name to look up is 
> "_nsdb._tcp." 
> > > > + NSDB name. I don't see why NSDB name must be a 
> "domain" and only 
> > > > a domain.
> > > 
> > And it says that there "domain" is strictly in the RFC1034 sense.  
> > What that means exactly we should ask of a DNS expert, but my own 
> > reading of these RFCs and experience says that "domain" in 
> the RFC1034 
> > sense is not in the "administrative domain" sense, nor in the "a 
> > domain name for which there is an SOA RR", or even in the "a name 
> > below which there exist other names" (and why should there be any 
> > names below the Name of an SRV RR?).  Here "domain" really 
> seems to mean "domain name".
> > 
> I'll ask the DNS directorate to clarify if the Name field of 
> a SRV RR may contain a hostname.
> 
> Regardless of that, there does not appear to be any advantage 
> to using SRV RRs. 
> 
> An FSN is defined as:
> 
> A fileserver will use DNS to resolve the nsdb_hostname. For 
> that, we've been discussing these two alternative:
> 
> In (b) there is an extra step but no functional benefit. As 
> we've discussed, prefetching and caching of these lookups may 
> be used to mitigate any performance issues. This is true for 
> both options with

It could be a fine idea, in principle, to leverage the SRV structure.
In principle, a name with many address records can indicate a variety of
actual NSDB servers, but the SRV structure is perhaps more convenient
for doing this.  I would find it easier to administer a name
specifically for NSDB SRV use than to have to invent a name that
resolves to a set of addresses of a set of servers.  That's indeed what
SRV is good for.  And, of course, it's good for more than that: it
allows some targets to be more preferred than others.

		Craig

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Sep 2009 11:49:27 -0500

> allows some targets to be more preferred than others.

I've worked with a DNS (and other) namespace management tool that made
it trivial to represent clusters of hosts providing a given, named
service, and which generated multi-A and SRV RRsets.  I don't know that
this is true in general though, but I'd imagine that all such tools
should support both, multi-A and SRV RRsets.  So there should be little
advantage to one or the other from that point of view, though in
principle SRV RRs, being intended for this purpose, ought to have the
advantage.

You can't "telnet _some._srv.name", and so on, and that is, I believe, a
good thing, but others might disagree.

In operational terms SRV RRs have the advantage for a number of reasons,
starting with the priority and weight fields, the fact that each target
host can be running the service on a different port, and the fact that
SRV RRs are neutral w.r.t. IP address type (v4 or v6).  There's also the
fact that each SRV RR's target host can be multi-homed without affecting
the load distribution (whereas that's not the case when it comes to
using A RRs for clustering).  There are probably other operational
advantages.

There are NFSv4 operational advantages to multi-A RRsets though, mostly
that a single query gets you all the answers you need, whereas with SRV
RRs one must do at least two queries: one for the SRV RR, one for
resolving the selected target to an IP address, plus any additional
lookups implied, plus any additional lookups should the selected target
not be available.  (One can do all the target resolution in parallel,
but the most common resolver doesn't support asynchronous operation,
sadly.)

Finally, I expect the DNS directorate to prefer that we use SRV RRs for
NSDB location.  I don't know that for a fact -- I'm just speculating.
It does seem like SRV RRs are intended for this sort of use, therefore
we should use them.  I understand the appeal of multi-A RRsets, and that
SRV RRs are a pain to use (i.e., the lack of an established C API for
doing SRV RR resolution), but I don't think these are good enough
reasons to not use SRV RRs.

Nico
--

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 14 Sep 2009 14:46:33 -0400

> Sent: Monday, September 14, 2009 12:49 PM
> To: Everhart, Craig
....
> There are NFSv4 operational advantages to multi-A RRsets 
> though, mostly that a single query gets you all the answers 
> you need, whereas with SRV RRs one must do at least two 
> queries: one for the SRV RR, one for resolving the selected 
> target to an IP address, plus any additional lookups implied, 
> plus any additional lookups should the selected target not be 
> available.  (One can do all the target resolution in 
> parallel, but the most common resolver doesn't support 
> asynchronous operation,
> sadly.)

Well, if the DNS server adds A/AAAA records with the SRV data, it isn't
an extra round trip.  RFC 2782 doesn't explicitly require such
"additional information" records, but it mentions them multiple times,
both in the context of keeping the DNS response down to a given size.

Is that no longer typical practice?  It keeps the best case down to a
single query/response, the same as a pure address query.

		Craig

> Finally, I expect the DNS directorate to prefer that we use 
> SRV RRs for NSDB location.  I don't know that for a fact -- 
> I'm just speculating.
> It does seem like SRV RRs are intended for this sort of use, 
> therefore we should use them.  I understand the appeal of 
> multi-A RRsets, and that SRV RRs are a pain to use (i.e., the 
> lack of an established C API for doing SRV RR resolution), 
> but I don't think these are good enough reasons to not use SRV RRs.
> 
> Nico
> --

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Sep 2009 14:08:00 -0500

On Mon, Sep 14, 2009 at 02:46:33PM -0400, Everhart, Craig wrote:
> > ...

Oh, good point.  I'd forgotten about that.

RFC1035 doesn't "require" additional section records, but does say that
such and such RR type "cause type A additional section processing for
the host..." (e.g., for MX).  RFC1035 pre-dates RFC2119, whereas RFC2782
follows and references it.  I'd translate "causes type A additional
section processing..." into "it's RECOMMENDED that ..." (though if I
were implementing a DNS server I'd research this carefully).  IOW, I
agree that RFC2782 doesn't REQUIRE this :)

And presumably authoritative servers should include additional answers
only for SRV targets for which they are authoritative.

Clients should be prepared to do additional lookups.

> single query/response, the same as a pure address query.

I wouldn't know if/which DNS servers (caching and otherwise) do that.
It'd sure be nice if they all did.  And it'd be nice to know which ones
do.

Nico
--