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

[Daniel Senie <dts@senie.com>]

At 05:12 PM 4/28/2003, Brad Knowles wrote:
>At 11:33 PM -0700 2003/04/27, David Conrad wrote:
>
>>  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).
>
>         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.

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.

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