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