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

Danny Mayer mayer at ntp.org
Mon Mar 9 12:29:10 UTC 2009


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.

Danny

> Martin


-- 
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