[AFS3-std] DNS SRV Resource Records for AFS

[David Boyes]

On 10/5/09 7:58 PM, "Jeff Hutzelman" <jhutz@cmu.edu> wrote:

> --On Monday, October 05, 2009 07:31:27 PM -0400 David Boyes
> <dboyes@sinenomine.net> wrote:
>=20
>> One thought I had was that most TCP stack implementations these days
>> provide some form of trivial DNS caching
>=20
> I've found that most TCP stacks implement TCP, not DNS.  DNS lookups are
> usually handled in some piece of user-mode code, probably a library, whic=
h
> may vary from one application to the next.  And in fact, most interfaces
> I've seen for performing DNS queries do _not_ do extraneous caching.

Sorry -- I spend a lot of time on machines where IP is not the dominant
protocol, so I tend to refer to the whole group of IP-related protocols as
part of the IP stack. Terminology difference; sorry if that generated
confusion.=20

> I would agree that the interfaces provided by most platforms for
> hostname-to-IP-address lookups, such as gethostbyname() or getaddrinfo(),
> do provide some sort of caching.  Some systems even provide interfaces
> which combine all of the operations needed to establish a TCP connection,
> including hostname lookup, and these also often do some sort of caching.
> But those interfaces aren't what we're interested in here, as they are
> generally not useful for resolving other types of records, such as the SR=
V
> and AFSDB records the present document discusses.

Mmf. If you're digging that far down, I think there are bigger problems.

> Much more likely is that implementations will
> somehow manage not to re-query when they should.

Thus some question about whether that needs to be an application function a=
t
all.=20

>> Another thought would be to do a SHOULD/MUST division -- recommend that
>> clients SHOULD re-resolve the name each time it looks up the VLDB or oth=
er
>> component, but MUST resolve it and select it once at minimum.
>=20
> Beware.  SHOULD is actually very strong, and usually doesn't mean what
> people think it means.  In particular, it doesn't mean "we think this is =
a
> good idea"; it means "you have to do this unless there's a valid reason n=
ot
> to and you fully understand the implications".

I'm aware of what SHOULD means. I actually think that overall it may be a
better thing to do it that way in that the entire system would have a
consistent view of the state of the name->address or name->service mapping
and can react in a consistent fashion. I'd much rather see that mapping in
the hands of a system-wide function than in a specific application. But,
we're getting away from the draft on that speculation.

> I don't think we want to say clients SHOULD re-resolve SRV records on eve=
ry
> VLDB lookup; that's likely to be way more often than necessary and places
> unnecessary burden on nameservers, unless you assume the existence of a
> cache in the right place.  It's better not to second-guess the DNS
> infrastructure, and instead simply REQUIRE that clients obey the TTL
> provided them.

But didn't you say earlier that you weren't worried about too many
queries....?=20

>> That way old
>> clients are still in compliance
>=20
> I'm not terribly in favor of watering down new specifications so that
> preexisting implementations can claim to be in compliance.  New specs
> should be written to describe correct behavior, not redefine incorrect
> behavior as correct.
>=20
> Note that this is different from designing new protocols or protocol
> versions such that new implementations will interoperate with old ones.

I guess I think that tolerating the pre-existing clients in a form that
recognizes that there are differing interpretations, capturing those
differences, and that new implementations will need to deal with that is
important enough to give them a break. Controlled evolution can take over
from there, but reality seems to dictate that we will have a spectrum of
clients and servers and that we need to recognize that fact in the
documentation we produce.

>> best practice can be toward some kind of DNS caching on
>> clients as well as servers.
>=20
> I don't believe specifying best practices for operation of the DNS is in
> scope for this group.

Hmph. Saying "Having a DNS cache available is beneficial to the operation o=
f
this application" doesn't strike me as specifying DNS operations.
=20
> However, there is much to be said for being able to lower the TTL on an R=
R
> and then expect that clients will notice a change to that record within o=
ne
> TTL of when the data changes.  This ability is critical if one wishes to
> move, upgrade, renumber, or replace servers without spending long periods
> of time tracking down clients which haven't picked up the change.

Thus the original question.