bind-9.3.2-33.fc5

Bill Larson wllarso at swcp.com
Mon Sep 25 14:41:52 UTC 2006


On Sep 25, 2006, at 7:01 AM, broadcast wrote:

>
> Mark Andrews wrote:
>> 	Why not?  They are basically the ones that are breaking the
>> 	resolution.  The DNS is a co-operative effort.  Everyone
>> 	needs to do their part.
>>
> We are a service provider and we can't have such a problem as people
> will simply move to others who can resolve the names they want without
> needing to report a problem every day about websites don't open or
> names don't resolve.
> If this is made by the upgrade we made to our DNS servers then maybe
> downgrading again may be a good idea?!

Look, Mark gave ***A*** possibility for an answer to your problem,  
but you provided very little useful information about the problem  
itself.  The issue of delegation problems is one possibility but  
without more specific information there is little chance of actually  
tracking down the problem.

Can you provide us with a specific example of a domain that you are  
having problems with?  Providing this information will allow someone  
to confirm or deny that there is a DNS problem with the specific  
example(s) that you give.  If the problem lies with the delegation of  
the domain, then you will know that there is little that you can do  
yourself to solve the problem.  If this is true, then others will be  
seeing the same type of problem.  If the problem does NOT lie with  
the DNS information then there is a problem with your setup which  
needs to be addressed.  Identifying if the problem lies with you or  
somebody else is a good first step to solving the problem.

Since the issue is only with resolving information, this test setup  
doesn't even have to be authoritative for any zones - simply  
configure a caching DNS server.  Do this on a test system and not  
your production system to keep your customers happy.  This should  
take about ten minutes of your time to confirm, not a tremendous  
amount of effort - probably less time than typing all of your  
messages.  Be aware that simply downgrading the version of BIND,  
without consideration of what version of you are downgrading to, may  
leave you open to other issues, such as security.

If the problem lies with the DNS information itself, then downgrading  
BIND won't matter, the problem will still exist and will be causing  
you, and everyone else, problems.  This is the point that Mark and  
Barry have been trying to get across to you.

This delegation issue may NOT be the answer to your specific problem,  
but this is the the direction all discussion went.  Without more  
information other possibilities cannot be addressed.

BIND-9.3 is IPv6 aware, again as Mark identified.  If there is a  
problem with how your setup, either servers or network, deal with  
IPv6 then there could obviously be a problem.  If the problem lies  
with your handling of IPv6, have you considered using the "-4" option  
to "named" to force IPv4 only handling of DNS?  This should only be  
considered as a short term, stopgap, solution until your system can  
properly handle IPv6.

In all honesty, the issue of DNS delegation was simply a shot in the  
dark because you provided very little useful information to try and  
troubleshoot the problem itself.  The same is true for the  
possibility of an IPv6 issue with your setup.  You solve your  
particular problem you will need to provide more specific information  
and perform very specific operations to try and actually solve your  
problem.  Help us to help you.

If you feel that you have the solution already, by downgrading the  
version of BIND you are using, then do it, but be aware of the  
possible concerns that this may cause.  Be aware that these types of  
solutions generally just mask the real issue which will come back to  
haunt you in the future.  If you really want our assistance then you  
will need to provide more information about the problems that you are  
experiencing.

Bill Larson

>> 	There is NO nameserver that can resolve everything fine.
>>
>> 	Named is IPv4 and IPv6 transport aware so it sees
>> 	misconfigurations that IPv4 only nameservers don't usually
>> 	see because it asks for both A and AAAA address.  The later
>> 	are not usually satisfied by glue and as such named sees
>> 	the zone content and hence the configuration errors.
>
> Why does it resolve the failed to resolve names after restarting named
> daemon?
>
> Thank you
>
>



More information about the bind-users mailing list