Re: bind-9.3.2-33.fc5 - DNS

This is a discussion on Re: bind-9.3.2-33.fc5 - DNS ; > I have 2 public DNS servers one as primary and the other one is secondary, > both are behind PIX firewall > > Environment: > > BIND Version: bind-9.3.2-33.fc5 > > OS: FC5 > > PIX: Cisco Adaptive Security ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Re: bind-9.3.2-33.fc5

  1. Re: bind-9.3.2-33.fc5


    > I have 2 public DNS servers one as primary and the other one is secondary,
    > both are behind PIX firewall
    >
    > Environment:
    >
    > BIND Version: bind-9.3.2-33.fc5
    >
    > OS: FC5
    >
    > PIX: Cisco Adaptive Security Appliance Software Version 7.1
    >
    > Problem Description:
    >
    > 1- Most queries are resolved just fine but some returns the following error
    > "Server Failed", not timed out.
    >
    > By restarting the named daemon those records resolves fine for a while then
    > the problem happens again.


    These will almost always be the result of a bad delegation.

    > 2- When restarting named daemon sometimes I get the error that it is already
    > running when trying to start, and by initiating /etc/init.d/named start, it
    > starts fine afterward.


    The restart script doesn't wait for named to finish exiting.
    Talk to the scipts maintainer.

    > 3- Some records are cached even though TTL is expired.


    You are confused. Named will not return a expired record.

    > Steps taken to resolve the issue:
    >
    > 1- Removed the DNS Inspection from PIX firewall.
    >
    > 2- Defined edns packet size to 512.
    >
    > 3- Defined max ttl cache
    >
    > Configuration File:
    >
    > options {
    >
    > directory "/var/named";
    >
    > dump-file "/var/named/data/cache_dump.db";
    >
    > statistics-file "/var/named/data/named_stats.txt";
    >
    > version "Whatever";
    >
    > allow-query { any; };
    >
    > allow-recursion { localhost; trusted; };
    >
    > blackhole { badguys; };
    >
    > notify yes;
    >
    > max-cache-ttl 172800;
    >
    > max-ncache-ttl 172800;
    >
    > datasize default;
    >
    > max-cache-size 80000000;
    >
    > allow-transfer { secondaries; };
    >
    > also-notify {192.168.1.101; 192.168.10.9;}; // all zones
    >
    > allow-notify { secondaries; };
    >
    > recursive-clients 30000;
    >
    >
    > --
    > Dry Networks don't pass by lakes !!!

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

    Hello,
    Mark Andrews wrote:

    > These will almost always be the result of a bad delegation.


    What do yuo mean by bad delegation? the domains am trying to resolve
    are not hosted on my servers, they are external domains.

    > > 2- When restarting named daemon sometimes I get the error that it is already
    > > running when trying to start, and by initiating /etc/init.d/named start, it
    > > starts fine afterward.

    >
    > The restart script doesn't wait for named to finish exiting.
    > Talk to the scipts maintainer.


    Thank you, I will do that.

    > > 3- Some records are cached even though TTL is expired.

    >
    > You are confused. Named will not return a expired record.


    I also have internal DNS server the same version and let me give you an
    example about what happened.
    example.com = 1.1.1.1 then changed to 2.2.2.2
    from internal DNSexample.com resolves to 2.2.2.2, but External DNS
    still resolves to 1.1.1.1
    when i restart the daemon or rndc flush it starts resolving to 2.2.2.2


    thank you, I appreciate your help

    Regards



  3. Re: bind-9.3.2-33.fc5

    In article ,
    "Shaheen" wrote:

    > Hello,
    > Mark Andrews wrote:
    >
    > > These will almost always be the result of a bad delegation.

    >
    > What do yuo mean by bad delegation? the domains am trying to resolve
    > are not hosted on my servers, they are external domains.


    He means that there's some mismatch between the way that the domain is
    delegated and the actual configuration of the servers it's delegated to.
    It's not your problem, it's a problem with those external domains --
    their DNS administrators have screwed up in some way.

    > > > 3- Some records are cached even though TTL is expired.

    > >
    > > You are confused. Named will not return a expired record.

    >
    > I also have internal DNS server the same version and let me give you an
    > example about what happened.
    > example.com = 1.1.1.1 then changed to 2.2.2.2
    > from internal DNSexample.com resolves to 2.2.2.2, but External DNS
    > still resolves to 1.1.1.1
    > when i restart the daemon or rndc flush it starts resolving to 2.2.2.2


    That means that the TTL of the old record hasn't expired yet. What was
    the TTL of the 1.1.1.1 record, and how long did you wait after changing
    it?

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***



  4. Re: bind-9.3.2-33.fc5

    Hello, Barry

    On 9/22/06, Barry Margolin wrote:
    >
    > In article ,
    > "Shaheen" wrote:
    >
    > > Hello,
    > > Mark Andrews wrote:
    > >
    > > > These will almost always be the result of a bad delegation.

    > >
    > > What do yuo mean by bad delegation? the domains am trying to resolve
    > > are not hosted on my servers, they are external domains.

    >
    > He means that there's some mismatch between the way that the domain is
    > delegated and the actual configuration of the servers it's delegated to.
    > It's not your problem, it's a problem with those external domains --
    > their DNS administrators have screwed up in some way.




    Ok I understand but why does it resolve just fine after restarting the named
    daemon? if it is an issue form outside my network why does it occur only
    within it? i mean other DNS servers at other places can resolve just fine.

    > > > 3- Some records are cached even though TTL is expired.
    > > >
    > > > You are confused. Named will not return a expired record.

    > >
    > > I also have internal DNS server the same version and let me give you an
    > > example about what happened.
    > > example.com = 1.1.1.1 then changed to 2.2.2.2
    > > from internal DNSexample.com resolves to 2.2.2.2, but External DNS
    > > still resolves to 1.1.1.1
    > > when i restart the daemon or rndc flush it starts resolving to 2.2.2.2

    >
    > That means that the TTL of the old record hasn't expired yet. What was
    > the TTL of the 1.1.1.1 record, and how long did you wait after changing
    > it?



    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***




  5. Re: bind-9.3.2-33.fc5

    In article ,
    "Wael Shaheen" wrote:

    > Hello, Barry
    >
    > On 9/22/06, Barry Margolin wrote:
    > >
    > > In article ,
    > > "Shaheen" wrote:
    > >
    > > > Hello,
    > > > Mark Andrews wrote:
    > > >
    > > > > These will almost always be the result of a bad delegation.
    > > >
    > > > What do yuo mean by bad delegation? the domains am trying to resolve
    > > > are not hosted on my servers, they are external domains.

    > >
    > > He means that there's some mismatch between the way that the domain is
    > > delegated and the actual configuration of the servers it's delegated to.
    > > It's not your problem, it's a problem with those external domains --
    > > their DNS administrators have screwed up in some way.

    >
    >
    >
    > Ok I understand but why does it resolve just fine after restarting the named


    The first time named accesses a domain, it uses the information in the
    delegation to find the authoritative servers. The authoritative servers
    often include their version of the NS records in the response, and this
    then gets cached in its place. These records may cause problems later
    when the TTL of the original delegation expires -- for instance, there
    may not be any glue records for them.

    > daemon? if it is an issue form outside my network why does it occur only
    > within it? i mean other DNS servers at other places can resolve just fine.


    That's harder to explain. Sometimes it's a timing issue, other times
    it's due to the version of BIND being used.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***



  6. Re: bind-9.3.2-33.fc5

    In article ,
    Barry Margolin wrote:
    >In article ,
    > "Wael Shaheen" wrote:
    >
    >> Hello, Barry
    >>
    >> On 9/22/06, Barry Margolin wrote:
    >> >
    >> > In article ,
    >> > "Shaheen" wrote:
    >> >
    >> > > Hello,
    >> > > Mark Andrews wrote:
    >> > >
    >> > > > These will almost always be the result of a bad delegation.
    >> > >
    >> > > What do yuo mean by bad delegation? the domains am trying to resolve
    >> > > are not hosted on my servers, they are external domains.
    >> >
    >> > He means that there's some mismatch between the way that the domain is
    >> > delegated and the actual configuration of the servers it's delegated to.
    >> > It's not your problem, it's a problem with those external domains --
    >> > their DNS administrators have screwed up in some way.

    >>
    >>
    >>
    >> Ok I understand but why does it resolve just fine after restarting the named

    >
    >The first time named accesses a domain, it uses the information in the
    >delegation to find the authoritative servers. The authoritative servers
    >often include their version of the NS records in the response, and this
    >then gets cached in its place. These records may cause problems later
    >when the TTL of the original delegation expires -- for instance, there
    >may not be any glue records for them.
    >
    >> daemon? if it is an issue form outside my network why does it occur only
    >> within it? i mean other DNS servers at other places can resolve just fine.

    >
    >That's harder to explain. Sometimes it's a timing issue, other times
    >it's due to the version of BIND being used.


    Or perhaps your query was the first one in a long enough time for all
    information to have timed out, or the first one since that server was
    started.

    >--
    >Barry Margolin, barmar@alum.mit.edu
    >Arlington, MA
    >*** PLEASE post questions in newsgroups, not directly to me ***
    >*** PLEASE don't copy me on replies, I'll read them in the group ***

    --
    Tom Schulz
    schulz@adi.com



  7. Re: bind-9.3.2-33.fc5


    Thomas Schulz wrote:
    > >That's harder to explain. Sometimes it's a timing issue, other times
    > >it's due to the version of BIND being used.

    >


    I believe this is a version problem too, am thinking about downgrading
    my BIND servers.
    What version should I use, which will be the more stable?
    Thank you



  8. Re: bind-9.3.2-33.fc5

    On Thu, Sep 21, 2006 at 06:57:12AM -0700, Shaheen wrote:
    ....
    > I also have internal DNS server the same version and let me give you an
    > example about what happened.
    > example.com = 1.1.1.1 then changed to 2.2.2.2
    > from internal DNSexample.com resolves to 2.2.2.2, but External DNS
    > still resolves to 1.1.1.1
    > when i restart the daemon or rndc flush it starts resolving to 2.2.2.2

    ....


    If the second server is slaving its copy of the zone to a "master" copy
    on the first server, then you have forgotten to update the zone's serial
    number. Otherwise, the TTL has not expired on the old record, even
    though you have changed the old record. No matter what name server you
    use, there will be some propagation delay.


    --
    Joe Yao
    -----------------------------------------------------------------------
    This message is not an official statement of OSIS Center policies.



+ Reply to Thread