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

[Brad Knowles <brad.knowles@skynet.be>]

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.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"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 <dnsop-request@cafax.se>.