Harlan Stenn <[EMAIL PROTECTED]> wrote:
> Richard> The bug is that ntpq should not be interpreting the refid at all!
> Richard> It's a text string, not an IP address and should not be treated as
> Richard> one. Yes, sometimes the refid IS an IP address but it still should
> Richard> be treated as a simple text string!
>
> How can the code tell the difference between a refid that is a string and
> one that is an IP address?
>
> I want to stop doing this resolution altogether, but the last time I asked
> Dave about this he said he wanted to keep the lookup in place, even though
> it is only useful for IPv4.
I've just tried a test with ntpq 4.2.4 and I do not see this behaviour
of looking up the refid in the DNS for ntpq -p, or ntpq -np. ntpq -p
does show lookups for the PTRs of the server IPv4 addresses in my host
config and A lookups for the corresponding names. However I'm running
ntpd 4.2.2 not 4.2.4, so could the refid lookups be in ntpd?
As I read the code of ntpq, the refid string is passed to decodenetnum()
to check if it is a valid IP address, which in turn calls getaddrinfo()
with hints flag AI_NUMERICHOST. On Solaris the man page for that says
If the AI_NUMERICHOST bit is set in the ai_flags member of
the hints structure, then a non-null nodename string must be
a numeric host address string. Otherwise an error of
EAI_NONAME is returned. This flag prevents any type of name
resolution service (such as DNS) from being called.
I don't think the original poster said what OS he's using, but perhaps
there is a difference here?
--
Ronan Flood <[EMAIL PROTECTED]>
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
