[ntp:questions] http://www.ntp.org/ => a blank page?

Danny Mayer mayer at ntp.org
Mon Mar 9 14:05:20 UTC 2009


Dave Hart wrote:
> On Mar 9, 12:08 pm, ma... at ntp.org (Danny Mayer) wrote:
>> Dave Hart wrote:
>>> On Mar 9, 3:47 am, ma... at ntp.org (Danny Mayer) wrote:
>>>> Dave Hart wrote:
>>>>> [...] platform
>>>>> and site policies come into play
>>>> getaddrinfo() which is used by all newer apps returns both IPv4 and IPv6
>>>> unless you specify a particular type. It has nothing to do with site
>>>> policy and they do not come into play. The query is controlled solely by
>>>> the app. The app may have additional controls on whether or not it wants
>>>> to query for IPv4, IPv6 or both.
>>> You might want to spend a little time curling up with RFC 3484,
>>> "Default Address Selection for IPv6"
>> You might want to curl up with the BIND9 source code.
> 
> What does that have to do with this?  I'm sure it's a good read, but
> it does not define the standard.  We've been discussing getnameinfo()
> generically, not any particular implementation.  I note you do not
> respond on the point of site policies coming into play.
> 

As far as I am aware there is no way to change the list of addresses
returned via any available knobs so how are site policies involved? You
cannot change getaddrinfo() unless you implement your own and there is
no purpose to doing so. The order of addresses records is indeterminate
by DNS standards and anything that is being done by getaddrinfo() is
implementation/OS specific and cannot be depended upon. See the
discussion in namedroppers.

>>> http://www.rfc-editor.org/rfc/rfc3484.txt
>>> With RFC 3484 support, getaddrinfo sorts its results so that
>>> applications processinig the results in order follow the selected
>>> policy.  Given that the RFC came out of Microsoft Research, it should
>>> be no surprise that a certain widely-used platform respects RFC 3484.
>>> Take particular note of the policy tables described in RFC 3484 and
>>> how they allow site policies to come into play.
>> Yes and that RFC is being discussed right now in namedroppers since
>> there are a number of problems with it, particularly section 6 rule 9
>> causing operational problems.
> 
> If you're aware of default address selection why do you say site
> policies have nothing to do with getaddrinfo?
> 

Because there is no way to change the order. That's not a site policy,
it's an O/S-specific implementation

>> A platform-specific implementation of
>> getaddrinfo() should not be depended on for behavior. DNS makes no
>> guarantee of sort order of the returned records, nor should there be any
>> expectation by the app of the order. If Microsoft has chosen to
>> implement this in their DNS Client service, well I always turn it off as
>> being useless overhead and causes me operational problems.
> 
> To each his own.  I see Microsoft's caching DNS resolver as
> functionally equivalent to the common practice on Unix of running a
> local recursive nameserver.  In both cases TTLs are respected, and
> responses are cached locally.  Seems like a win to me.
> 

Not really. I run into too many issues with the O/S caching results.
That's what the nameserver is for.

>>>>> It sounds like you use a disconnected IPv6 network alongside a
>>>>> connected RFC1918 v4 network internally.  I wonder if you could get by
>>>>> using only link-local addresses for your internal IPv6 network?  I
>>>>> believe that would solve the problem because your stack would know it
>>>>> can't connect to a global v6 address from a machine with only link-
>>>>> local v6 addresses.
>>>> The stack has no knowledge of whether it can connect to a global IPv6
>>>> address. Only the routers will be able to do that.
>>> Since link-local addresses by definition are not routable, routers do
>>> not come into play.  Any IPv6 stack understands the difference between
>>> link-local and global addresses, and will not attempt to connect to a
>>> global remote address using a link-local local address.  Hence the
>>> results Martin saw that only machines with IPv6 global addresses were
>>> having trouble with names returning AAAA as well as A.
> 
> I'm not sure why you quoted this, but since you failed to respond I
> take it you're no longer claiming IPv6 stacks need routers to discern
> link-local from global addresses.
> 

site-local addresses should be sufficient to reach global addresses.
Routers are needed for that but the site-local prefix needs to be
configured so that auto-config finds it.

>>>>> This may indeed be the best option for your configuration.  I wouldn't
>>>>> call it a good solution, though.  Your machines should be able to
>>>>> handle seeing AAAA records via IPv4-accessible DNS even if they can't
>>>>> use them.  I'd dig into configuring the machines to use IPv6 as a last
>>>>> resort before considering DNS server-based AAAA filtering.
>>>> It cannot be done by the DNS.
>>> This reads as a non-sequiter.  I have no idea what "It" is that cannot
>>> be done.
>> DNS cannot remove records returned to the requestor.
> 
> Certainly not if it's going to be standards compliant, but Martin is
> clever enough to hack BIND to filter AAAAs if he so desires, I'm
> sure.  I wouldn't advise it, but lots of people are doing lots of
> wierd things to deal with the generally failing transition to IPv6.

Not for something like this. Not even I would attempt to do something as
complicated as that even if I thought it worth while which I obviously
don't.

> Speaking of which, it's been two years that you've been working on
> integrating Martin's Windows IPv6 patches to ntp.  Is it still in
> progress?  https://support.ntp.org/bugs/show_bug.cgi?id=501#c8
> 

Yes.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the questions mailing list