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

Richard B. Gilbert rgilbert88 at comcast.net
Mon Mar 9 14:47:27 UTC 2009


Danny Mayer wrote:
> Martin Burnicki wrote:
>> Danny,
>>
>> Danny Mayer wrote:
>>> Martin Burnicki wrote:
>>>> Rob wrote:
>>>>> Steve Kostecke <kostecke at ntp.org> wrote:
>>>>>>> But it has two IPv4 addresses. Under the address 204.152.184.138 it
>>>>>>> works OK.
>>>>>> That's our off-site back-up.
>>>>> Well, in DNS it says:
>>>>> www.ntp.org has address 128.4.35.16
>>>>> www.ntp.org has address 204.152.184.138
>>>>> www.ntp.org has IPv6 address 2001:4f8:0:2::23
>>>> The IPv6 entry in the DNS may lead to another error on a local site which
>>>> we have recently encountered.
>>>>
>>>> I'm explicitely pointing out that what I describe below is *not* a
>>>> problem of the NTP site, even though users may think so after the first
>>>> glance. Anyway, I'd like to mention this here just for the records.
>>>>
>>>> The problem we've been observing was that we have been unable to access
>>>> e.g. support.ntp.org, www.isc.org and some other sites from some machines
>>>> in our local intranet, even using different browsers. The browsers
>>>> returned an error, or the page was displayed only after quite a number of
>>>> seconds delay. From other machines on our local intranet access to those
>>>> sites was fast and without problems.
>>>>
>>>> After some digging around we found out the problem occurs only if the DNS
>>>> server also returns an IPv6 address for this site.
>>>>
>>> The DNS will always return what is requested. An AAAA record is just as
>>> valid as an A record. If your client requests only A records if will
>>> return just A records. If it is not specific it will return both.
>> Yes, and in the meantime we've found out that if the local machine has got a
>> global IPv6 address assigned it may try to reach the external host using
>> IPv6 instead of IPv4 even though we have no IPv6 connection to the
>> internet.
>>  
>>>> Our intranet is behind a NAT router which only has IPv4 connection to our
>>>> ISP. If both an IPv4 and IPv6 address for a host on the internet is
>>>> returned then applications may try to connect via IPv6 first, which fails
>>>> in this case.
>>>>
>>> The NAT router needs to be replaced. IPv6 has been around for a very
>>> long time and there is no excuse for a manufacturer not to support IPv6
>>> as well as IPv4.
>> Unfortunately it's not primarily a problem of the NAT router. Our ISP does
>> not provide IPv6 support, yet.
>>  
> 
> Yes, that's a global chicken and egg problem. There's no demand yet for
> it so the ISP's don't invest in the IPv6 infrastructure to support it
> and since the ISP's don't support it the users don't try and use it.
> This cannot go on for much longer, IPv4 addresses will be exhausted in a
> few years and then they will have no choice.
> 
>>>> Interestingly, some application/machines try to use IPv4 first, whereas
>>>> others try to use IPv6 first. I'm not sure whether this is a global
>>>> configuration option of the IP stack, or due to the application. A good
>>>> way to see what's going on is to use wget.
>>>>
>>> If the client is using getaddrinfo() and is not specific about which
>>> type of address it wants it will get back both. You can specify to
>>> getaddrinfo() just one or the other. The older gethostbyname() only
>>> supports IPv4 addresses and that's all you will get, but it's still
>>> present in a lot of applications.
>>>
>>>> I know a possible solution would be to use a IPv6-over-IPv4 tunnel to the
>>>> internet. However, if this has not been set up then access may fail for a
>>>> reason which is not obvious.
>>>>
>>> The solution to this is to support IPv6. IPv6-over-IPv4 is a hack that
>>> should go away.
>> I'm aware of this. However, since our ISP doesn't provide IPv6 support we
>> can only fallback to IPv4, or use an IPv6-over-IPv4 tunnel.
>>  
>>>> AFAIK some browsers, e.g. Firefox, can be configured to prefer either
>>>> IPv4 or IPv6, so this can be solved without a tunnel.
>>>>
>>>> A good solution would be to let the local DNS server discard IPv6
>>>> addresses returned from forwarders while maintaining IPv6 suuport for the
>>>> local zone/network, but I currently don't know if/how this can be
>>>> configured for bind 9.
>>>>
>>>> Danny, any ideas?  ;-))
>>>>
>>> That cannot be done. Your DNS accepts all requests and returns the
>>> results based on the request.
>> That's a pity.
>>
> 
> No, that's the way it should be. DNS cannot pick and choose what it
> returns. Not only would it violate just about every RFC in sight but
> noone would use it since it could not be depended upon for service.
> 
>>> Why are you using forwarders? They  
>>> shouldn't be used unless you absolutely have to.
>> Why shouldn't forwarders be used? 
>>
> 
> It provides no benefit to you and you have single points of failure.
> 
>> We often tell people to use their ISP provider's NTP server(s) (if the ISP
>> provides them) rather than letting every dumb workstation query the time
>> directly from the primary NTP servers (USNO, PTB, ..).
>>
>> I think with DNS it's similar. The DNS server in our intranet is
>> autoritative for the local names in our intranets, and all global queries
>> are forwarded to our ISP's DNS servers, which can query the root servers,
>> if required.
>>
> 
> DNS is very different from NTP. You cannot compare. DNS is a distributed
> hierarchical database and it does not make a difference if you get an
> answer from nameserver A the first time you ask and nameserver B the
> next time. If you do this with NTP you have different and unrelated NTP
> timestamps.
> 
>> Isn't this the best way to keep unnecessary traffic from the root servers?
>>
> 
> Not really. BIND9 has it build in and you refresh about once in 14
> hours. The real load on the root servers are the garbage queries. I once
> asked Paul how much he was seeing on F-root and he said it was about 80%
> garbage.
> 
>>> It makes you dependent 
>>> on the system to whom you are forwarding queries and you get no benefit
>>> from that. You should be doing your own requests. I know of two use
>>> cases that require the use of forwarders. I doubt that they apply to you
>>> and one of those cases doesn't apply to queries outside your network.
>> Our ISP provides several DNS servers, so it's not a problem if one of them
>> is temporarily offline. If there's a problem at our ISP's site then we
>> don't have internet access at all, so we don't need to worry about missing
>> global DNS service.
>>
> 
> You are dependent on the ISP's DNS being up and able to respond. Since
> you can make the queries yourself why bother with their DNS? If there's
> no connectivity all queries will fail. I'm not sure how the idea of
> going to one's ISP for DNS service got started but it doesn't make a lot
> of sense from a network point of view. Almost all queries are unlikely
> to be shared with other users of the ISP so it's not faster and you have
> added a single point of failure to your network.

Where, other than your ISP, would you go for DNS?  If you are a home 
user what choices do you have?  If you are responsible for a multi-user 
site it may make sense to operate your own DNS?  I'm working from a 
two-user site and using my ISP's DNS.  I'm paying Comcast for internet 
access and I consider name service to be part of the package; so, 
evidently, does Comcast.




More information about the questions mailing list