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

[rad@twig.com (Richard Doty)]

On Tue, 29 Apr 2003 16:47:13 -0400  Daniel Senie wrote:
> 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.

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 
> 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>.
> 
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.