Subject: RE: RFC 2782: SRV naming convention

From: "Christian Huitema" <[email-masked]>
Date: Mon, 18 Jun 2001 09:55:57 -0700

> How about "_smtp._http.example.com"? (Mail tunnelled over http) Along
> those lines, can the protocol or service be further decomposed into
> layers? What about "_smtp._http._tcp.example.com" (Mail tunnelled over
> http which runs over tcp)?

Something like that might limitations of the SRV format perceived by
several WG -- notably SIP and IMPP. The problem occurs when a service
can run on several protocols. For example, SIP can run over UDP, TCP and
possibly SCTP or TLS; IMPP services can be provided through SIMPLE,
APEX, PRIM and possibly others. How can we discover not just a server
name and a port, but also a transport protocol and possibly an
application protocol? If a given client only supports some of the
options, how do we restrict the discovery to the server that support
common options?

Another extension that has been suggested is to take account some form
of locality, as in "I am in subnet number X, in domain example.com, and
I want to find an LDAP server; which is the most appropriate one?"

-- Christian Huitema=20

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 19 Jun 2001 18:38:48 -0400

> I want to find an LDAP server; which is the most appropriate one?"

Does the SRV protocol prohibit a nameserver from manipulating priorities
and/or weights in its answers depending on the source address of the
requesting client? Perhaps this "localization" can be done within the
implementation and there's no need to burden the protocol with it. This
would just be a more sophisticated version of the A-record sorting
mechanisms in use today.

- Kevin

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 19 Jun 2001 17:09:05 -0700

> requesting client?

No.

DNS itself does that.  It has nothing to do with SRV.

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 19 Jun 2001 23:02:57 -0400

Paul A Vixie wrote:

> DNS itself does that.

I disagree. It's just a volatile RRset that happens to change in accordance
with the requesting client's source address. Surely this violates no
DNS specs. Alternatively, each client is being answered from a different
DNS namespace (like BIND 9's "view"s). I see answer-differentiation being
legal under either formulation.

- Kevin

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 20 Jun 2001 01:59:14 -0700

> ... It's just a volatile RRset that happens to change in accordance
> DNS specs.

It wouldn't be DNS at all if it were "volatile" in that way.  DNS, on the
other hand, is coherent.  If you want to synthesize responses in that way,
be sure to write a draft and be sure to specify that TTL is always zero.

> Alternatively, each client is being answered from a different DNS
> namespace (like BIND 9's "view"s). I see answer-differentiation being

BIND's "view" mechanism is intended for use by disparite reachability domains.
Sending multiple incoherent answers into a single reachability domain would
be a protocol (the DNS protocol, that is) violation.  People who do it with
A RR's to try to get naively modelled clients to come to a "closer" web server
are just fooling themselves (and irritating the rest of us).

But with an RFC that specified TTL 0 (among other things) this could become
part of the protocol.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 20 Jun 2001 11:00:55 -0400 (EDT)

> legal under either formulation.

You are confused, view is two different sets offered based on some 
selection ciriteria, but the set is unchanged in each view for a
"long" time. 

DNS protocol does not allow DNS servers to update zone contents on the 
fly, but someone may claim that the protocol does not outlaw it either. 

I know that some load balancers give out different answers (not just
reorded) at different times, if that is a subset of and RRset that is
fine, as this is same as trunction even if the TC bit is not on.  

DNSSEC is going to make life hard for these boxes :-) 

	Olafur

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 20 Jun 2001 12:26:43 -0400

> selection ciriteria, but the set is unchanged in each view for a

With all due respect, I think you're the one who is confusing the two different
potential justifications I gave for why a nameserver might give out different
answers, to different clients, to the same question, in quick succession. I
apologize if I wasn't clear enough. The first justification is "it's volatile,
and happened to change in between queries". The second justification is "I was
answering the first client from one namespace, and the second client from
another namespace". The second justification has nothing to do with volatility
-- it might *always* answer the same way to any given client -- and is
indistinguishable from "view"s unless one agrees with Paul's "disparate
reachability domains" explanation/exception.

> fly, but someone may claim that the protocol does not outlaw it either.

Depends on what your definition is of "on the fly". Volatile data has always
been accommodated in DNS, and with Dynamic Update, there is no longer a
requirement for a nameserver to reload a whole zone just to pick up the change
of one RRset. So I think we've arguably already crossed the "on the
fly" threshold. Data is changing "on the fly" in nameservers all over the place.
The only new issue that is being raised here is: is it permissible to change DNS
data on a query-by-query basis? Is that perhaps what you meant by "on the fly"?

> fine, as this is same as trunction even if the TC bit is not on.

Actually, if for the sake of argument, answer-differentiation is indeed
forbidden, doesn't that load-balancer behavior qualify as giving out a partial
RRset and isn't it therefore forbidden by RFC 2181? I don't think the fact that
the different answers are subsets of some larger "definitive" RRset really saves
the behavior from this (alleged) illegality.

> DNSSEC is going to make life hard for these boxes :-)

Among others...

- Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 20 Jun 2001 12:27:25 -0400

Paul A Vixie wrote:

> It wouldn't be DNS at all if it were "volatile" in that way.

RFC 1034, Section 2.3, Assumptions about usage:

> - Most of the data in the system will change very slowly (e.g.,
>      mailbox bindings, host addresses), but that the system should
>      be able to deal with subsets that change more rapidly (on the
>      order of seconds or minutes).
>

Sounds like a description of volatile data to me.

Or is the emphasis in your sentence on the phrase "in that way", i.e. it's OK for
data to be volatile in general, you just can't change it in accordance with
something as volatile and/or incoherent as the requesting client's source
address? I don't think protocol specifications should be in the business of
trying to outlaw evil intent. The reasons *why* a piece of data is changed to a
certain (legal) value, or why it changes often, is of no concern to the protocol.

> DNS, on the

I think TTL=0 is a red herring. There is nothing in the DNS specs that says
resource-record data can't change more frequently than the TTL interval, in
practice this happens all of the time, and I'm not aware of any
DNS implementation that attempts to enforce any such restriction on
change-frequency. It is simply understood that if you change data more frequently
than TTL, caching servers and the clients which rely on them, may have "stale"
data more often than otherwise. This is a downside that an implementor may be
more than happy to live with.

> be a protocol (the DNS protocol, that is) violation.

What specific part of the protocol is being violated? I don't remember seeing any
references to "reachability domains" in any of the main DNS RFCs.

- Kevin

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Jun 2001 13:11:19 -0400

>DNSSEC is going to make life hard for these boxes :-)

Not necessarily.  Just sign all the combinations you want to send out ahead
of time.  The signature chain only improves the likelyhood that the answer
you got is honest, the chain does not speak to its uniqueness.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

---

From: Rob Austein <[email-masked]>
Date: Fri, 29 Jun 2001 10:52:38 -0400

Kevin,

Going back to your original question:

   Date: Tue, 19 Jun 2001 18:38:48 -0400
   From: Kevin Darcy <[email-masked]>

As Paul Vixie pointed out, this is a DNS protocol issue, not specific
to SRV.

The entity acting as a name server can perform this kind of
manipulation if and only if it can update the serial field of the SOA
RR in the authoritative zone.  Name servers don't do that except when
acting as the master server in the dynamic update protocol.  Changing
zone content without changing the SOA serial field is a protocol
violation.

More precisely, given the following four queries, performed in order,
and assuming no zone cuts below miskatonic.edu:

#1 QNAME=miskatonic.edu.                    QTYPE=SOA QCLASS=IN
#2 QNAME=_foo._bar.cthulhu.miskatonic.edu.  QTYPE=SRV QCLASS=IN
#3 QNAME=_foo._bar.cthulhu.miskatonic.edu.  QTYPE=SRV QCLASS=IN
#4 QNAME=miskatonic.edu.                    QTYPE=SOA QCLASS=IN

If the answers to queries #1 and #4 are the same, the answers to
queries #2 and #3 must also be the same.

Of course, there's nothing to stop you from writing a program which is
both a name server and a dynamic update client.  In theory you could
also write a program which acts as an authoritative name server and
which generates new zone content on the fly at whim, but be sure to
generate a new SOA serial value to go with each new whim, and have fun
making sure that the other authoritative name servers for this zone
return precisely same whimsical zone content as this name server does
for a given SOA serial value....  But for a conventional name server
operating with zones that come from boring old files generated by some
outside source, the answer to your question is "no".

Sorting A RRs is fundamentally different from changing zone content:
DNS itself makes no promises at all about ordering of RRs within an
RRset, so a name server can present the RRs in any order it likes.

Hope this clarifies things a bit.

--Rob

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 29 Jun 2001 20:07:25 -0400

Use of AXFR/IXFR for zone-data replication is an optional part of the
protocol, as is Dynamic Update, so how can SOA serial increment, which is only
defined in the context of AXFR/IXFR and Dynamic Update, be mandatory?

Note that, as usual, I'm not challenging the common understanding here.
Obviously we all understand -- or at least assume -- that SOA serial should be
incremented to reflect zone-data changes. I'm challenging only the
*specification* of the behavior, which, like many things in the older DNS
RFCs, seems riddled with loopholes.

(And I've heard second-hand that one increasingly-popular DNS implementation,
which does not use AXFR/IXFR for replication, doesn't bother with consistently
incrementing its serials. If true, then perhaps this issue isn't quite as
academic as it may seem...)

- Kevin

---

From: Rob Austein <[email-masked]>
Date: Fri, 29 Jun 2001 21:48:07 -0400

Date: Fri, 29 Jun 2001 20:07:25 -0400
   From: Kevin Darcy <[email-masked]>

   Use of AXFR/IXFR for zone-data replication is an optional part of the
   protocol, as is Dynamic Update, so how can SOA serial increment, which is
   only defined in the context of AXFR/IXFR and Dynamic Update, be
   mandatory?

See RFC 1034, page 27, last paragraph.  While the specific "usage"
described in that paragraph has never been recommended, the context
makes it clear that the author of RFC 1034 believed that SOA serial
numbers were relevant to normal queries, not just to zone transfer.

   (And I've heard second-hand that one increasingly-popular DNS
   implementation, which does not use AXFR/IXFR for replication, doesn't
   bother with consistently incrementing its serials. If true, then perhaps
   this issue isn't quite as academic as it may seem...)

If the implementation in question acts as the master server in the DNS
dynamic update protocol and does not increment SOA serial numbers when
doing so, that's a bug.

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 29 Jun 2001 20:54:37 -0700

> numbers were relevant to normal queries, not just to zone transfer.

That paragraph may use mandatory-sounding language, but the section as a whole
is prefaced by language which quite unequivocally states that the use of the
AXFR "part" of the protocol is optional, albeit preferred. As a matter of
strict interpretation, it's far from clear that the mandatory-sounding language
has relevance to anything outside of the AXFR "part" of the protocol, i.e. "if
you want to use AXFR to replicate zone data, you must do X, Y and Z".

Reasonable people can, of course, disagree as to what the *intent* of the
specification was. As it happens, I think we probably agree on what the intent
was. But loopholes are by definition _unintended_ lacunae in a rule or set of
rules.

As a practical matter, does anyone know of any DNS software which actually
cares about serial numbers in any context besides AXFR/IXFR and/or Dynamic
Update? I mean, for example, is there any paranoid caching resolver out there
that would invalidate cache entries based on seeing a higher serial number for
the containing zone? In the absence of a cut-and-dried rules-conformance
argument, I'm just questioning what the practical value is of imposing a
burdensome serial-increment requirement on an implementation that wants to
"customize" its responses to different clients. Is it merely because such
behavior challenges our long-cherished assumptions about how DNS is "supposed"
to work?

- Kevin

---

From: Robert Elz <[email-masked]>
Date: Sat, 30 Jun 2001 08:08:21 -0700

Date:        Fri, 29 Jun 2001 20:54:37 -0700
    From:        Kevin Darcy <[email-masked]>
    Message-ID:  <[email-masked]>

  | That paragraph may use mandatory-sounding language, but the section
  | as a whole is prefaced by language which quite unequivocally states
  | that the use of the AXFR "part" of the protocol is optional,

AXFR is optional, no doubt about it.   That a serial number identifies
zone contents isn't even in doubt.

  | As a practical matter, does anyone know of any DNS software which actually
  | cares about serial numbers in any context besides AXFR/IXFR and/or Dynamic
  | Update?

I'm not aware of one, but the possibility has often been postulated.

  | I mean, for example, is there any paranoid caching resolver out there
  | that would invalidate cache entries based on seeing a higher serial number
  | for the containing zone?

That would be wrong.   The TTL specifies how long the data is allowed to
be cached.  "wrong" in the sense that nothing about the SOA specifies that
should happen - the server is free to invalidate its cache any time it likes
of course.

But what the server could do, upon seeing a SOA that is the same as an earlier
one it saw, is revert all TTLs for records from the zone since the earlier
SOA was received to the values they had when the RR was initially learned.
That is, undo any decrementing that has been done to the TTL, as receiving the
same SOA tells the server that if it asked again, it would get the same data
returned - along with the same (or perhaps higher if the RR wasn't received
directly) TTL.

What makes this hard to actually implement, is that it is quite difficult
to determine whether a name is actually in a particular zone or not.
Doing that is likely to be as much, or more, work than simply refreshing
the RR separately.   Dynamic DNS requires this question be answered anyway,
so nodes doing that will have the answer, and might start adding the
optimisation (though with DynDNS the serial number is perhaps likely to
change so often that the benefits won't be there).  It is also possible that
some side effect of dnssec might provide similar benefits (I haven't looked
at that closely enough to be sure).

  | In the absence of a cut-and-dried rules-conformance
  | argument, I'm just questioning what the practical value is of imposing a
  | burdensome serial-increment requirement on an implementation that wants to
  | "customize" its responses to different clients.

The DNS provides a single global database.  If you want a protocol that
provides different answers to different clients, then you should be inventing
a new protocol.   Rob's messages were 100% correct.

For what its worth, I don't like the bind9 "view" stuff, for just the same
reason - however, something is only broken if you can demonstrate that it is
broken.  As long as it is possible to guarantee that clients always see the
same data (no matter which server they query, no matter which method they
use to fetch the data) for one instance of the zone, then everything appears
to be working.

  | Is it merely because such behavior challenges our long-cherished
  | assumptions about how DNS is "supposed" to work?

Our assumptions about how the DNS is supposed to work is actually the
definition of the DNS.   The RFCs etc are an attempt to capture that, which
are not always perfect.  That's why we attempt to fix them where needed.

kre