[ntp:hackers] NTPv4 Brian Version

todd.glassey at att.net todd.glassey at att.net
Fri Aug 12 17:12:43 UTC 2005


Brian is dead on from a production auditing perspective ...

Todd

--
Regards,
Todd

This message (including any 
attachments) contains confidential 
information intended for a 
specific individual and purpose, 
and is protected by law. If you 
are not the intended recipient, 
you should delete this message. 
Any disclosure, copying, or 
distribution of this message, or 
the taking of any action based on 
it, is strictly prohibited. 


 -------------- Original message ----------------------
From: Brian Utterback <brian.utterback at sun.com>
> My thought on this is that there is a use case for preempt beyond yours.
> Suppose I am a network admin that has a bunch of stratum 2 and 3 servers 
> on my enterprise network. What I would like to do is configure all of my 
> clients to use all of these servers and then pare the list down to the 
> best 4 or 5 for each of them. If I had control of the naming service, I 
> might be able to have a single address resolve to them all, but I might 
> not be able to do that. So, to start with 10 or 15 actual server names
> and then have it winnow the list down to 4 or 5 would be a great thing.
> 
> David L. Mills wrote:
> > Brian,
> > 
> > I take it the reason you want the first-only option is so you can use 
> > different subzones and restrict the number of servers from each. The 
> > option should take values one or greater. Zero or missing says take them 
> > all.
> > 
> > The option to not re-resolve doesn't make sense. What happens now in 
> > manycast is that occasionally a server times out due whatever cause, at 
> > which point the manycast server honks for replacements. Occasionally, 
> > all preemptable associations are demobilized to yield a level playing 
> > field. Do you want it to not resolve for replacements in those cases?
> > 
> > Right now with pool servers configuration can happen only at startup, so 
> > essentially we have the case where re-resolution is not possible. Should 
> > it eventually be possible, would you want it to act like manycast? I'd 
> > like to pour all the discovery schemes through the same 
> > constraints/restraints if at all possible.
> > 
> > I'm still sanding off rough edges with this stuff, but I am keenly 
> > interested in your comments on manycast, which has the same issues as 
> > the pool.
> > 
> > Dave
> > 
> > Brian Utterback wrote:
> > 
> >> Along with the new preempt keyword, I would like to see two others
> >> added for the server line. One would be to enable taking all the IP
> >> addresses returned instead of just the first, and the other to
> >> enable the re-resolve at a later time to find more servers. I think
> >> that these three  options are orthogonal to each other and each could 
> >> be useful individually, without the others.
> >>
> >> David L. Mills wrote:
> >>
> >>> Harlan,
> >>>
> >>> As I said in my last message, the operating system did change and it 
> >>> would seem cacheing might indeed be the culprit. If so, that blows 
> >>> the scheme right out of the water for our department and campus 
> >>> machines. Consider the response of the deparment and campus 
> >>> administrators if I request to turn cacheing off. Just to be sure, I 
> >>> did a nslookup followed immediately by another and two different 
> >>> packets came back. So, maybe the ntpd name resolver should use a 
> >>> short delay between calls and that would "fix" things.
> >>>
> >>> The more desirable workaround seems completely obvious to me; use all 
> >>> the replies in the packet, not just the first one. The responses I 
> >>> see returns eight addresses, more than enough for most cases.
> >>>
> >>> I've not touched the resolver components ever. The code is so badly 
> >>> written that the only recourse I see is to rewrite it or rebuild with 
> >>> the library of choice.
> >>>
> >>> Dave
> >>>
> >>> Harlan Stenn wrote:
> >>>
> >>>> Dave,
> >>>>
> >>>>> For whatever reason, the current implementation doesn't work, in that
> >>>>> It returns the same address for subsequent queries. This is new 
> >>>>> behavior
> >>>>> Not seen before.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> My belief is that the behavior change you see is:
> >>>>
> >>>> - an OS change
> >>>> - an OS configuration change
> >>>> - a change to the DNS server that sent the answer
> >>>>
> >>>> The problem is that ntp_intres:findhostaddr() calls getaddrinfo() and
> >>>> then uses the first address so returned.
> >>>>
> >>>> To address the problem we need to do what I suggested in the URL I
> >>>> mentioned in the previous message and find a way to grab up to N 
> >>>> addresses.
> >>>>
> >>>> I'll also mention that I find ntp_intres.c to be Obtuse and I really 
> >>>> wonder
> >>>> what happened that I did not cut us over to ntp_resolver.c .
> 
> -- 
> blu
> 
> Remember when SOX compliant meant they were both the same color?
> ----------------------------------------------------------------------
> Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
> Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers




More information about the hackers mailing list