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

[Daniel Senie <dts@senie.com>]

At 06:28 PM 4/29/2003, Brad Knowles wrote:
>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.

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?


>>                              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.

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. 

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.