DNS issues

["Jóhann B. Guðmundsson"]

On 04/23/2009 06:16 AM, Anne Wilson wrote:
> On Wednesday 22 April 2009 23:56:38 Richard Körber wrote:
>   
>> Hi!
>>
>> I just installed F11 beta and updated to the latest packages. It was
>> working fine so far, but then suddenly I got issues with domain name
>> resolving.
>>
>> When I use Firefox, Thunderbird, wget, whatever, I always get an error
>> message that the domain name could not be resolved. Anyhow the network is
>> up, DNS server IPs are set correctly and I can even use dig and ping to
>> successfully resolve domain names. When I enter a plain IP address at
>> Firefox, it also fetches the page correctly.
>>
>> Configuration files seem to be correct, there are no hints in the log
>> files, I even checked that there is no proxy set, but I found nothing. I
>> created a clean user to make sure there is no configuration messed up. I
>> rebooted the system, but still got that issue. I'm totally clueless now...
>>
>> Is this a F11 bug? I have had a look at bugzilla, but I wasn't sure what I
>> should search for.
>>
>>     
> This happens from time to time on my F10 netbook, too, although it's not a 
> frequent event.  Rebooting is the only way I've found out of it.  Whatever 
> causes it, it's common to both versions.
>
> Anne
>   

I've experienced the same ( or similar ) seemed to be domain specific.  

Had open a bug ( #496979 ) then closed it again cause we could duplicate
it on
debian and f10 and thus deemed the fqdn in question had an broken dns setup.

Also on http://udrepper.livejournal.com/20948.html

"DNS NSS improvement

In glibc 2.9 I already implemented an improvement to the DNS NSS module
which optimizes the lookup of IPv4 and IPv6 addresses for the same host.
This can improve the response time of the lookup due to parallelism. It
also fixes a bug in name lookup where the IPv4 and IPv6 addresses could
be returned for different hosts.

The problem with this change was that there are broken DNS servers and
broken firewall configurations which prevented the two results from
being received successfully. Some broken DNS servers (especially those
in cable modems etc) only send one reply. For this reason Fedora had
this change disabled in F10.

For F11 I’ve added a work-around for broken servers. The default
behavior is the same as described above. I.e., we get the improved
performance for working DNS servers. In case the program detects a
broken DNS server or firewall because it received only one reply the
resolver switches into a mode where the second request is sent only
after the first reply has been received. We still get the benefit of the
bug fix described above, though.

The drawback is that a timeout is needed to detect the broken servers or
firewalls. This delay is experienced once per process start and could be
noticeable. But the broken setups of the few people affected must not
prevent the far larger group of people with working setups to experience
the advantage of the parallel lookup.

There are also ways to avoid the delays, some old, some new:

    * Install a caching name server on this machine or somewhere on the
      local network. bind is known to work correctly.
    * Run nscd on the local machine. In this case the delay is incurred
      once per system start (i.e., at the first lookup nscd performs).
    * Add “single-request” to the options in /etc/resolv.conf. This
      selects the compatibility mode from the start.

All of these work-arounds are easy to implement. Therefore there is no
reason to not have the fast mode the default which in any case will work
for 99% of the people."

However the end user will not blame the incompetent DNS admin but Fedora
( or what ever program he's using at the time.. firefox thunderbird
network manager etc.. )
when the M$ machine next to him manages to reach the site successfully
while the Fedora machine will not..

Are these "workarounds" in forums docs ?

JBG

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20090423/24ea85e8/attachment.htm>