Dave Hart wrote:
> On Jan 12, 6:52 pm, [email protected] (Danny Mayer) wrote:
>> And line 340-341 makes it clear that it's doing it's own lookups:
>> // there was a new CNAME, look again.
>> WspiapiSwap(pszName, pszAlias, pszScratch);
>>
>> That also means that it is not using the resolvers since CNAME restart
>> is the job of a resolver and that means that this code cannot make use
>> of DNSSEC and other security changes being added to DNS.
> 
> Take a step back and read the code some more.  On line 232 is the call
> to gethostbyname(), the IPv4-only resolver entrypoint.  CNAME records
> can be followed by that function, resulting in a return of both the
> canonical text name via hostent.h_name as well as one or more IPv4
> addresses in hostent.s_addr.  Only in the case that the resolver
> returns a different h_name with zero addresses in the hostent will
> this code loop around for another call to gethostbyname.
> 
> I'm not an expert on why gethostbyname would or would not include any
> addresses when resolving through a CNAME.  I do know gethostbyname is
> the old-style resolver, though.  I'm not sure that helps with DNSSEC
> and other security changes being added to DNS, I've seen no hint of
> support for such in Windows DNS clients or servers.
> 

But I am an expert in this area. This code has a layering violation and
I won't agree to support that.

Danny

> Cheers,
> Dave Hart
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions

Reply via email to