Subject: draft-ietf-dnsop-serverid-01.txt

From: David Conrad <[email-masked]>
Date: Wed, 23 Apr 2003 17:51:26 -0700

So, this draft is going to expire soonish.

Is there anything I need to do to it?  I don't remember any additional 
comments since Atlanta.

Can it be pushed to last call?

Tnx,
-drc

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Rob Austein <[email-masked]>
Date: Sun, 27 Apr 2003 16:16:49 -0400

> Can it be pushed to last call?

I was really hoping that somebody else would say this, but ok, I'll
say it, and will recuse myself from the chair role on this draft if it
seems necessary.

While I understand and respect the author's intentions in attempting
to remove the BIND-specific aspects of an existing hack, this opens up
a nasty can of worms:

1) The draft asks IANA to allocate a new TLD, and a class-specific TLD
   at that;

2) The draft specifies behavior for the (conceptual) zone
   corresponding to that new class-specific TLD which is totally
   inconsistant with the usual DNS data coherence model.

Furthermore, even ignoring the above issues, this looks like a
protocol document than an ops document.

I can see two ways forward, depending on what the author and the WG
want to do:

a) Strip this back down to an Informational doc describing an existing
   BIND hack; or

b) Change focus to trying to draft some useful behavior for the STATUS
   opcode, and move the work over to DNSEXT.

Comments?

---

From: Paul Vixie <[email-masked]>
Date: 27 Apr 2003 23:25:09 +0000

> ...

i agree on all three points.  the problem we solved with VERSION.BIND
back in bind8 and now with the recent addition of HOSTNAME.BIND caused
some other problems.  it's unquestionably bad that we pirate a TLD in
the CHAOS namespace for our version/hostname data.  it's questionably
bad that we do it by default, requiring people who want version/hostname
privacy to have to make a config change to get it.  however, not doing
these things would have been worse, and trying to get IETF and IANA to
allocate us some kind of QNAME/QCLASS/QTYPE for it would have been much
much far worser even.

>    opcode, and move the work over to DNSEXT.

while i agree with your complaints about the draft, i think that your
proposed alternatives are worse.  STATUS will run into untold middlebox
problems and will also take several years to finish the main part of the
argument about.  having an rfc number, even if only informational or
experimental, that would seem to sanction TLD piracy of this form would
be the biggest can of worms mentioned so far on this topic.

therefore i support drc's draft as written, since it's the least of all
known evils.  right now a number of non-BIND implementations answer for
VERSION.BIND and sometimes also HOSTNAME.BIND in the CHAOS class, just
for feature-level competition.  i regret choosing .BIND as the pirate TLD
in the CHAOS class for this; it should have been .NAMESERVER or something
else, and there should have been at least a technote describing it, and
i should have sought an experimental rfc for it.
-- 
Paul Vixie
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 28 Apr 2003 02:22:51 +0200

At 11:25 PM +0000 2003/04/27, Paul Vixie wrote:

>  for feature-level competition.

	Note that NSD already supports VERSION.SERVER, presumably as a 
result of the work on the draft (or maybe some earlier document or 
discussion).

>                                  i regret choosing .BIND as the pirate TLD

	The draft is pretty old, and appears to me to have some useful 
information and suggestions.  I'd at least like to see it go towards 
an experimental or informational RFC, and perhaps beyond.

	However, I must also agree with Rob that this seems to be more of 
a protocol/policy issue and I'm not sure that it should be dealt with 
in DNSOP.  His suggestion of passing this to DNSEXT seems to be 
appropriate.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: David Conrad <[email-masked]>
Date: Sun, 27 Apr 2003 19:22:06 -0700

Hi,

Given their fundamental nature, I am curious as to why you didn't raise 
these issues way back when I first submitted this draft or at the DNSOP 
meeting where this was discussed, however...

> to remove the BIND-specific aspects of an existing hack, this opens up

It would seem difficult to do pretty much anything in the IETF these 
days without opening up a nasty can of worms.

> protocol document than an ops document.

The draft attempts to document existing operational practice and modify 
that practice slightly so it is more generally acceptable to non-BIND 
implementations.  It also tries to address an operational requirement 
of being able to identify which machine is responding to a query by 
extending the existing practice.  It is working code (in at least 3 
independent DNS servers I am aware of).

There is no modification to the DNS protocol proposed in the draft.  
There are no new RR types defined or clarification of any existing RR 
type behavior.  I do not believe it appropriate for this draft to be in 
DNSEXT.

> a) Strip this back down to an Informational doc describing an existing

It was always my intent for this to be informational.

>    opcode, and move the work over to DNSEXT.

You forgot the smiley.

> Comments?

This draft attempts to extend an existing practice in as simple a way 
as possible to address an immediate operational concern, namely being 
able to determine which nameserver out of a set of anycast'ed 
nameservers is responding to a request.  It would be distressing if 
this were to get bogged down in yet another IETF swamp.

Rgds,
-drc

---

From: Randy Bush <[email-masked]>
Date: Sun, 27 Apr 2003 21:33:44 -0700

> meeting where this was discussed, however...

because rob is shy and i raised some of them and another rather
fundamental one.  what i really need to know is the unique identity
of the server who gave me the result i just received in response to
a 'normal' query.  this is especially needed in an environment
where servers may be anycast.  this may be an edns thing.

i.e., why do i care what broken version of software some server is
running if i am not sure it is the server which gave me the result?

randy

---

From: David Conrad <[email-masked]>
Date: Sun, 27 Apr 2003 22:25:32 -0700

Randy,

Feel free to come back after you've actually read the draft.

In particular, the third and fourth paragraphs of section 4.  I added 
the fourth paragraph specifically for you as you seemed  confused in 
Atlanta.  Even put you into the acknowledgments.  The least you could 
do is read it.

Thanks,
-drc

---

From: Randy Bush <[email-masked]>
Date: Sun, 27 Apr 2003 22:39:46 -0700

> Atlanta.  Even put you into the acknowledgments.  The least you could 

i did read the draft.  you don't get my point.  and i wasn't in
atlanta, my wife was dying.  anything else?
</clue>

randy

---

From: David Conrad <[email-masked]>
Date: Sun, 27 Apr 2003 22:55:04 -0700

> i did read the draft.  you don't get my point.

Obviously not.  Want to try to speak for yourself instead of having Rob 
interpret for you?

> and i wasn't in
> atlanta, my wife was dying.

My condolences on your loss.  I guess it must have been in Yokohama.

>  anything else?

Yes.

Speak for yourself instead of getting other people to act as your 
mouthpiece.

If you have issues with a draft, bring them to the attention of the 
author in a timely manner either directly or via the working group 
mailing list.

> </clue>

Indeed.

Thanks,
-drc

---

From: Paul Vixie <[email-masked]>
Date: 28 Apr 2003 05:58:21 +0000

[email-masked] (David Conrad) writes:

> > ...  what i really need to know is the unique identity of the server
> > who gave me the result i just received in response to a 'normal' query.
> > this is especially needed in an environment where servers may be
> > anycast.  this may be an edns thing.

it would be pretty easy to use edns to solicit/carry a server identity blob
but in thinking about this i've been unable to determine what that would
have to look like.  answering nameserver's hostname might not be fully
qualified, answering nameserver host addresses might not have working PTR,
so putting a hostname blob in won't work.  the nameserver service address
might be NAT'd, and in addition, might be the same as a local rfc1918
address nearby the initiator, so, putting a host address blob in won't work.

if one assumed the existence of an 802.3 48-bit address (ethernet, fddi, etc)
and further assumed that these were universally unique, then one could put
one or more of these (a host might be have more than one attached interface)
into an edns blob... but it would not help the initiator to do anything except
know that two responses had come from the same distant, yet anonymous,
nameserver.  and it could be spoofed for anti-security reasons.

all of this stuff would be subject to middlebox corruption, either by
middleboxes who chose to change it when they shouldn't, or chose not to
change it when they should, or change it in wrong (or even evil) ways.

in other words, before we can decide how to encode or solicit or carry
nameserver identity, we have to decide the conceptual meaning of identity
as applied to nameservers.  if i loadbalance by running two processes on
a dual-processor system, but they respond to the same address/port combos
even though each one could have its own configuration, how many identities
do i have?  that sort of thing.
-- 
Paul Vixie
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Randy Bush <[email-masked]>
Date: Sun, 27 Apr 2003 23:04:13 -0700

> Obviously not.  Want to try to speak for yourself instead of
> having Rob interpret for you?

you provide how to ask a server to tell some things about itself.
but, in an anycast universe, when i have a result 'of interest' in
my hand, i don't know to which server to send the query.  and, if i
knew the server, i probably don't need to know, all i need to do is
send

  To: noc
  Subject: broken server

  the server with unique identity <foo> gave me the suspicious
  result <bar> to query <baz>.

unfortunately, i can not ascertain <foo>, and you provide no help.

> Speak for yourself instead of getting other people to act as your

<clue> i never asked rob to say anything.  please keep your black
helicopter theories down in caliwood.  and refrain from accusations
which you can not substantiate.

> If you have issues with a draft, bring them to the attention of
> the author in a timely manner either directly or via the working
> group mailing list.

i did.  you just did not get it.

randy

---

From: David Conrad <[email-masked]>
Date: Sun, 27 Apr 2003 23:33:26 -0700

Randy,

> unfortunately, i can not ascertain <foo>, and you provide no help.

Thank you.

If the server at a particular IP address returns <bar> to query <baz>, 
you issue a CH class ID.SERVER query to that IP address from the same 
client that received the suspicious result (making the assumption that 
the routing system has not changed the server that will receive that 
query).

If you do not have access to the client or there is a potential for the 
routing system to have changed which server will receive the CH class 
ID.SERVER query, you can either ask the NOC for the non-anycast IP 
addresses associated with the server and try each in turn or let the 
folks at the NOC do their job and figure it out themselves.

Does this address your concern or do I still not get it?

Rgds,
-drc

---

From: Randy Bush <[email-masked]>
Date: Mon, 28 Apr 2003 05:00:11 -0700

> the routing system has not changed the server that will receive that 

that assumption is not at all safe

randy

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 28 Apr 2003 16:22:09 +0200 (CEST)

> that assumption is not at all safe

Myself, I've found that said assumption holds fairly true for:

	verify problem @nameserver
	dig identifier @nameserver
	verify problem @nameserver

where the results from the two enclosing verifies are identical, and the
command sequence is executed one after the other in quick succession, and
is repeated several times to discount rapid routing instabilities, which
is what most people do when performing diagnostics of a problem.

Without going into unique identifiers being returned with the query (ref
Vixie's mail on the subject), this does appear to be a workable solution
for 95% of cases, the other 5% being silly load-balancer games (eg,
queries of one type being directed to a specific host) which you cannot
diagnose being external to the load-balancer.

--==--
Bruce.

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Apr 2003 09:54:50 -0700

Which is why I added the second paragraph (which you didn't quote) to 
my response to you.

Rgds,
-drc

---

From: Brad Knowles <[email-masked]>
Date: Mon, 28 Apr 2003 23:23:38 +0200

>  do i have?  that sort of thing.

	Indeed, when I set up the caching nameserver farm at AOL in '96, 
I had four DEC Alpha 4100s with four processors each, 4GB of RAM, and 
four copies of BIND 8 running on each machine, each process listening 
to a different virtual interface/IP address that was bound to the 
same physical address.  I benchmarked the processes, and each one 
could handle about 2000 queries per second, regardless of whether I 
was running one or four processes, or anywhere in-between.

	Dunno what happened to that farm.  I'll have to ask some friends 
& former co-workers who might still be there.

	I'm thinking we might be able to do this with hashes of public 
crypto keys.  Each process would need a unique public key/private key 
pair for successful secure control via remote processes (e.g., rndc 
and such like), and this key could be kept in a separate file for 
each instance of each nameserver.  You could either include the 
public part (or hash thereof) in each EDNS response, or include a 
portion.

	However, I fear that we're getting well away from operational 
issues, and this aspect of the discussion should probably be taken up 
within DNSEXT.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 28 Apr 2003 23:12:26 +0200

>  the routing system has not changed the server that will receive that

	Regretfully, in a load-balanced world this won't work.  An 
incoming query to a single IP address could be redirected to any of 
the back-end servers.

>  If you do not have access to the client or there is a potential for
>  the routing system to have changed which server will receive the CH
>  class ID.SERVER query, you can either ask the NOC for the non-anycast
>  IP addresses associated with the server and try each in turn or let
>  the folks at the NOC do their job and figure it out themselves.

	The server may not have a publicly accessible non-anycast or 
non-load-balanced address.

>  Does this address your concern or do I still not get it?

	I think we may have to just concede that there are going to be 
issues in an anycast or load-balanced environment, and maybe give 
some serious thought as to how we might work towards solving this 
problem in an EDNS environment.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 28 Apr 2003 23:02:21 +0200

>  unfortunately, i can not ascertain <foo>, and you provide no help.

	In an anycast or load-balanced world, I don't think it's possible 
to ascertain <foo>.  You would have to have the server attach some 
sort of unique identifier to each and every response, and that 
identifier would have to be persistent across program restarts, 
reboots, changes of IP address, etc....

	If the identifier wasn't unique in this manner, when someone 
complains that a particular server (according to the unique 
identifier) is screwed-up, you would have no way of determining which 
server it might have been.

---

From: Randy Bush <[email-masked]>
Date: Mon, 28 Apr 2003 10:23:09 -0700

> where the results from the two enclosing verifies are identical,
> and the command sequence is executed one after the other in quick
> succession, and is repeated several times to discount rapid
> routing instabilities, which is what most people do when
> performing diagnostics of a problem.

and do i have to hold my left leg up in the air and clap my hands
three times too? :-)

determinism is one of the redeeming features of digital computers.

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 28 Apr 2003 11:08:09 -0700

>> ...  what i really need to know is the unique identity of the
>> server who gave me the result i just received in response to a
>> 'normal' query.  this is especially needed in an environment
> it would be pretty easy to use edns to solicit/carry a server
> identity blob but in thinking about this i've been unable to
> determine what that would have to look like.

my experience in managing servers is that they have a unique
unicast ip address.  even the anycast ones do so that they can be
managed, transfer zones, ...

> the nameserver service address might be NAT'd

i don't care.  they deserve the hell into which they consigned
themselves.

> if i loadbalance by running two processes on a dual-processor
> system, but they respond to the same address/port combos even
> though each one could have its own configuration, how many
> identities do i have?

too many :-)

so cat the pid or something similarly disgusting.

randy

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Apr 2003 19:08:09 -0700

If it was, then you wouldn't have raised the issue, now would you?

Rgds,
-drc

---

From: Brad Knowles <[email-masked]>
Date: Tue, 29 Apr 2003 12:25:43 +0200

>  determinism is one of the redeeming features of digital computers.

	It's nice, but computers have also taught us that there are some 
systems where determinism is just not possible.  Chaos Theory would 
be virtually nothing without computers, and yet there is nothing 
deterministic about it.

---

From: Brad Knowles <[email-masked]>
Date: Tue, 29 Apr 2003 12:24:34 +0200

>  	verify problem @nameserver

	This is exactly what I did for my presentation at LISA 2002.  I 
ran 35 cycles like this (with a short sleep between cycles), and if 
all 35 came up exactly the same way (i.e., 1 & 3 worked, but 2 did 
not), then I considered this sufficient evidence to claim that the 
server is probably broken in the case of the middle query.

	Still, it's not deterministic, and any number of samples that can 
be counted by a human being are going to be vanishingly small 
compared to the real workload of the server.  At best, it's a "good" 
indication, for some value of "good".

---

From: Brad Knowles <[email-masked]>
Date: Tue, 29 Apr 2003 12:28:47 +0200

>  managed, transfer zones, ...

	True, but if you have multiple server processes per IP address, 
or perhaps multiple IP addresses with different "views" assigned to 
each?

>  i don't care.  they deserve the hell into which they consigned

	Problem is, they're now inflicting this hell on the rest of the 
Internet, and we also have to live with this problem.  It would be 
nice if we could give them some method to help make this easier.

>  so cat the pid or something similarly disgusting.

	Neither IP address nor pid will necessarily survive restarting 
the program, rebooting the machine, etc....  This makes it impossible 
to be able to determine which machine might have been broken when we 
get a claim at some time in the future.

	We need something that will be unique per server process (not per 
machine), and will be persistent across program restarts, server 
reboots, changes of IP address, etc....

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 29 Apr 2003 08:21:24 -0400

> Chaos Theory would 

Umm. Not Fractional dimension Hausdorff topology, not strange attractors,
not epicycles or any part of Ergodic theory, not ...

Preparing steak a la Mandelbrot requires a copious quantity of garlic.

"Nothing deterministic"... Hmm ... no.

---

From: Peter Koch <[email-masked]>
Date: Tue, 29 Apr 2003 21:23:50 +0200

> 	Regretfully, in a load-balanced world this won't work.  An 

You're right, but the draft targets another problem. It documents existing
practise while suggesting to change some implementation specific identifiers
to more generic ones. The draft's topic is initiated by an operational
question, i.e. identifying servers in an "anycast set". There's nothing I can
see in the dnsop charter that precludes this from being dealt with here,
so I'm in favor of keeping the document here and advance it.

To answer David's initial question, I do not feel it's ready for last call.

First, I agree that the en passant reassignment of the CHAOS class is a
problem. It's not even clear that IANA (whichever instance) is in charge of
allocating a TLD there, at least I do not see a hint in RFC 2929.
Since it's probably unwise to wait for an officially blessed TLD, it might
be better to change to a subdomain of the ARPA TLD. The problem remains
to find who's in charge of managing that in the CH class.

That aside, it should be explicitly stated that queries MUST NOT be
processed with recursion.

With respect to the Security Considerations I think it supports "security by
obscurity" a bit. While it may be useful to conceal or even change the
"real" IP address of an anycast nameserver in critical infrastructure to
avoid (D)DoS to this address, I'd rather not encourage filtering identity
queries. People may do so anyway, but even today I may choose (although it
wouldn't be too wise) not to answer DNS queries originating from certain IP
addresses. If it were that critical, IP address based filtering wouldn't
suffice. And, if Joe user is expected to submit the IDENT string with a
problem report, he should be able to retrieve it in the first place.

-Peter

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 29 Apr 2003 15:26:03 -0400

>    opcode, and move the work over to DNSEXT.

Not option B, please.

         Olafur

---

From: Daniel Senie <[email-masked]>
Date: Tue, 29 Apr 2003 16:47:13 -0400

At 05:12 PM 4/28/2003, Brad Knowles wrote:
> incoming query to a single IP address could be redirected to any of the 
> back-end servers.
>

I don't think that matters. The issue isn't about getting back and talking 
to that system. It's about being able to have SOME way for the owner of a 
set of systems to identify RELIABLY the server which generated a specific 
reply. It'd be helpful in tracking back problems, but need not be in a form 
that is readable to anyone but the owner of the servers. Given the number 
of issues I've seen with load balancers that play stupid DNS tricks, those 
systems would also benefit from having some sort of unique identifier 
transmitted for the same reason.

What should the identifier be? Something that's been hashed might work. I 
don't have a strong opinion on WHAT the value is, provided some method is 
determined for generating it. Given the concerns about multiple interfaces 
per machine, and multiple name service servers per host, it may make the 
most sense to consider some reasonable means of determining a "default" 
value (which would suffice for simple configurations of a single service 
server) and a way to configure the value for more advanced situations. 
Persistence across reboots/restarts could be addressed by configuration. 
It's not clear if it's worth the effort to try to devise an automated 
algorithm for dealing with complex environments, where simple configuration 
values might be sufficient.

---

From: [email-masked] (Richard Doty)
Date: Tue, 29 Apr 2003 22:59:07 +0000

On Tue, 29 Apr 2003 16:47:13 -0400  Daniel Senie wrote:
> reply.

I may be agreeing with you, not sure.

Asking an anycasted nameserver for its ident does not tell you who
answered some other query.  Without unicast access to the nameserver,
the nameserver ident info would need to be included in the answer
to a normal query.  (e.g. I ask for a PTR, get back PTR and ident of
nameserver that gave me the PTR)  Which sort of obviates a specific
ident query.

> It'd be helpful in tracking back problems, but need not be in a form

---

From: Brad Knowles <[email-masked]>
Date: Wed, 30 Apr 2003 00:28:21 +0200

At 4:47 PM -0400 2003/04/29, Daniel Senie wrote:

>  I don't think that matters. The issue isn't about getting back and
>  talking to that system.

	So far as that goes, that's fine.  My point was that the public 
IP address would not be a suitable identifier, because there may not 
be a public IP address.

>                          It's about being able to have SOME way for
>  the owner of a set of systems to identify RELIABLY the server which
>  generated a specific reply.

	Unless you find some way to modify the DNS protocol so that you 
can attach a unique identifier to each and every response, I don't 
see how this is possible.  At best, all you could determine is which 
server answered the VERSION.SERVER (or whatever) query, which would 
not necessarily have any bearing whatsoever on which server might 
answer any particular query before or after that one.

>                              It'd be helpful in tracking back problems,
>  but need not be in a form that is readable to anyone but the owner of
>  the servers. Given the number of issues I've seen with load balancers
>  that play stupid DNS tricks, those systems would also benefit from
>  having some sort of unique identifier transmitted for the same reason.

	This certainly is at least part of the goal.

>  What should the identifier be? Something that's been hashed might work.
>  I don't have a strong opinion on WHAT the value is, provided some
>  method is determined for generating it.

	Agreed.

>                                          Given the concerns about
>  multiple interfaces per machine, and multiple name service servers
>  per host, it may make the most sense to consider some reasonable
>  means of determining a "default" value (which would suffice for
>  simple configurations of a single service server) and a way to
>  configure the value for more advanced situations.

	The problem is that the situation where something like this is 
most needed is in those very complex situations.  The simple 
configurations probably don't need this sort of thing.

	So, while we might still end up going the KISS direction, I think 
we want to give some serious consideration to the more complex 
situations and try our best to hash these issues out pretty 
thoroughly.

---

From: David Conrad <[email-masked]>
Date: Tue, 29 Apr 2003 17:39:32 -0700

On Tuesday, April 29, 2003, at 03:28  AM, Brad Knowles wrote:
> 	True, but if you have multiple server processes per IP address, or 
> perhaps multiple IP addresses with different "views" assigned to each?

The draft says 'per server'.  I'll modify that to 'per server process'. 
  As 'views' are implementation specific, I'd prefer not to reference 
them.

> reboots, changes of IP address, etc....

A value in a configuration file won't suffice?

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 29 Apr 2003 17:33:57 -0700

Brad,

On Tuesday, April 29, 2003, at 03:24  AM, Brad Knowles wrote:
> 	Still, it's not deterministic, and any number of samples that can be 
> counted by a human being are going to be vanishingly small compared to 
> the real workload of the server.  At best, it's a "good" indication, 
> for some value of "good".

Unless the DNS protocol is modified to include server identifying 
information for each and every query (and we modify DNS using 
applications to archive that information), there is no solution to this 
problem that I am aware of.

Regardless of whether anycast is being used, you first have to notice a 
problem, then you have to figure out which IP address provided the bad 
response (since ordering of NSes between queries is not guaranteed).  
Given this is a multi-step process, the use of sampling is pretty much 
required.

However, this whole issue is a rare corner case.  If the draft was 
talking about something people had to rely on, the lack of determinism 
in a corner case might be worth arguing about.  However, the draft 
isn't.  It is talking about a minor modification to an existing 
convention that merely _helps_ when trying to track down a problem.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 29 Apr 2003 17:48:38 -0700

Peter,

Thanks for the comments (sorry for the slow reply)...

> To answer David's initial question, I do not feel it's ready for last 

OK.

> allocating a TLD there, at least I do not see a hint in RFC 2929.

Yeah.  So, I looked into this a (very small) bit and couldn't figure 
out who to ask at MIT to see if anyone there still uses CHAOSNet and/or 
whether it would be OK to use the .SERVER domain for this purpose (or 
perhaps to see what their reaction is to the existing use of .BIND).

> be better to change to a subdomain of the ARPA TLD.

I am highly skeptical this would be faster, but maybe I'm too cynical.

> The problem remains

Yes.  Suggestions welcome.

Agreed.

> queries.

I tend to agree that not providing identifying information sort of 
defeats the purpose, however my thought here was that if I didn't put 
"implementors SHOULD provide a way to limit who can query" we'd get 
stuck in the privacy/security swamp.

Rgds,
-drc

---

From: Daniel Senie <[email-masked]>
Date: Tue, 29 Apr 2003 20:58:51 -0400

At 06:28 PM 4/29/2003, Brad Knowles wrote:
> IP address would not be a suitable identifier, because there may not be a 
> public IP address.
>
> can attach a unique identifier to each and every response, I don't see 
> how this is possible.

I agree with you. The only way I see to provide information about the 
server that provided the response would be to include that information in 
the additional section of the response. Since the additional section would 
not normally contain whatever record we might add to express this, we would 
certainly learn just how liberal servers are in what they receive.

>  At best, all you could determine is which server answered the 
> VERSION.SERVER (or whatever) query, which would not necessarily have any 
> bearing whatsoever on which server might answer any particular query 
> before or after that one.

Once the response is received, no amount of asking further questions will 
give you certain knowledge.

If a need exists to solve this problem, it's likely the answer is in 
adjusting protocol. Are we interested in a solution?

> we want to give some serious consideration to the more complex situations 
> and try our best to hash these issues out pretty thoroughly.

It may well be that choosing the method of deciding the unique identifier 
is the least of our troubles. Let's worry about how to transmit the data, 
and if we can transmit the data first.

---

From: Brad Knowles <[email-masked]>
Date: Wed, 30 Apr 2003 03:19:33 +0200

At 5:39 PM -0700 2003/04/29, David Conrad wrote:

>  As 'views' are implementation specific, I'd prefer not to reference them.

	The technique used in BIND may be implementation specific, but 
the concept is not.  I would not be at all surprised if other servers 
adopt a similar technique, and therefore I'd suggest that the issue 
at least be considered.

>  A value in a configuration file won't suffice?

	That would be fine by me.  I don't really care what it is, so 
long as it meets the criteria previously mentioned.

---

From: Brad Knowles <[email-masked]>
Date: Wed, 30 Apr 2003 03:28:48 +0200

At 8:58 PM -0400 2003/04/29, Daniel Senie wrote:

>  I agree with you. The only way I see to provide information about
>  the server that provided the response would be to include that
>  information in the additional section of the response. Since the
>  additional section would not normally contain whatever record we
>  might add to express this, we would certainly learn just how
>  liberal servers are in what they receive.

	Hmm.  That's a cool idea -- use the additional section, perhaps 
with a TXT record containing the unique identifier information for 
the particular server in question.

	I like it.  I'm not sure, but I don't think it would require any 
protocol modifications, but we'd definitely want to give it some 
pretty extensive field testing first.

---

From: David Conrad <[email-masked]>
Date: Tue, 29 Apr 2003 18:58:50 -0700

Daniel,

On Tuesday, April 29, 2003, at 05:58  PM, Daniel Senie wrote:
> Once the response is received, no amount of asking further questions 
> will give you certain knowledge.

In theory, yup.

> adjusting protocol. Are we interested in a solution?

I suspect this would be a topic for DNSEXT.

In the meantime, given a server returning bogus information is most 
likely unrelated to routing instability which is where the CH class 
ID.SERVER hack wouldn't work, wouldn't it be nice to have an imperfect 
way of handling the vast majority of cases?

Rgds,
-drc

---

From: Brad Knowles <[email-masked]>
Date: Wed, 30 Apr 2003 13:12:33 +0200

>  way of handling the vast majority of cases?

	Having ID.SERVER is certainly an improvement over what we have 
now, which is nothing.  I think we can worry about the other issues 
separately.