Re: bind-9.3.2-33.fc5 - DNS

This is a discussion on Re: bind-9.3.2-33.fc5 - DNS ; > > Mark Andrews wrote: > > Named *is* stable. > > > > This is a classic case of "Garbage In - Garbage Out". > > > > People don't keep the NS RRsets in the parent and child ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: bind-9.3.2-33.fc5

  1. Re: bind-9.3.2-33.fc5


    >
    > Mark Andrews wrote:
    > > Named *is* stable.
    > >
    > > This is a classic case of "Garbage In - Garbage Out".
    > >
    > > People don't keep the NS RRsets in the parent and child
    > > zones in sync. People don't keep the glue (parent) and the
    > > real address records (child) in sync.
    > >
    > > The rules for making this work are pretty simple.
    > >
    > > KEEP THE RECORDS IN SYNC.
    > >
    > > Sometime you need to use a clue bat. There are plenty
    > > of sites which will check if the records are in sync and
    > > report if they are not.
    > >
    > > Registries and registrars could be doing there part as
    > > well by checking the delegation *before* they are added /
    > > changed to ensure that the RRsets are consistant with what
    > > the change would produce. They could also periodically
    > > be rechecking (e.g. daily) and reporting errors so they
    > > can be fixed.

    >
    > Thank you but that wont solve my problem I need to have a solution for
    > this, am having this problem with so many domains and I can't keep
    > asking other domain administrators to solve their problems


    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.

    > I just need a stable named that resolves everything fine.
    > Please advice


    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.

    Mark
    --
    ISC Training! October 16-20, 2006, in the San Francisco Bay Area,
    covering topics from DNS to DHCP. Email training@isc.org.
    --
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org



  2. Re: bind-9.3.2-33.fc5


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


    > 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



  3. Re: bind-9.3.2-33.fc5

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




  4. Re: bind-9.3.2-33.fc5


    Bill Larson wrote:
    > Look, Mark gave ***A*** possibility for an answer to your problem,
    > but you provided very little useful information about the problem
    > itself.

    Yes, I believe this is true, but that was becuase of the way this
    discussion went, no further information were asked.
    > 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

    Ok, here are some examples of domains that were failing to resolve
    www.3ouon.com.ps
    www.twseyatscript.com
    www.moashrat.com
    www.stooop.com
    These domains were failing frequently and to get them to resolve i had
    to restart the named daemon whenever they fail.


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


    I already did so, and I have a Cobalt machine with bind-8.2.3-C1
    configured outside my firewall as caching only server.
    after forwarding our public servers to the new caching server
    everything was fine .
    then the problem happened with some new domains not as frequently as it
    was before but it is still happens, so then I enabled the query logging
    on the caching server and I can see the following messages as an
    example.
    Sep 25 21:38:51 bns named[3722]: ns_resp: query(mail.yahoo.bz) All
    possible A RR's lame
    Sep 25 21:38:51 bns named[3722]: bad referral (. !<
    freevirtualstrippers.com) from [64.255.172.57].53
    Sep 25 21:38:51 bns named[3722]: bad referral (. !<
    freevirtualstrippers.com) from [64.255.172.57].53
    Sep 25 21:38:51 bns named[3722]: bad referral (. !< alsafidanone.com)
    from [64.20.49.218].53
    Sep 25 21:38:52 bns named[3722]: bad referral (181.24.in-addr.arpa !<
    115.181.24.in-addr.arpa) from [66.168.240.37].53
    Sep 25 21:38:52 bns last message repeated 2 times
    Sep 25 21:38:56 bns named[3722]: bad referral (. !< www-mailserver.com)
    from [64.20.39.26].53
    Sep 25 21:39:04 bns named[3722]: bad referral (231.61.in-addr.arpa !<
    44.231.61.in-addr.arpa) from [168.95.1.14].53
    Sep 25 21:39:04 bns named[3722]: bad referral (231.61.in-addr.arpa !<
    44.231.61.in-addr.arpa) from [168.95.1.14].53
    Sep 25 21:39:07 bns named[3722]: bad referral (. !< nokiacastle.NET)
    from [64.20.41.162].53

    one of the domains that failed on the caching server was www.6rb1.net
    and again it started working fine after restarting the named daemon.

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

    I currently don't have IPv6 implemented, but how can I use the "-4"
    option?

    Thank you



+ Reply to Thread