Thread Info
  • State Not Answered
  • Replies 7 replies
  • Subscribers 0 subscribers
  • Views 1907 views
  • Users 0 members are here
Options
Suggested

[8.285][BUG][FIXED] DNS Host definitions won't update if DNS cache is flushed

BAlfson
I'm using an ACC instance on Amazon EC2.  A few days ago, I received an email warning that the cluster-host was degraded and would be taken down, so I should stop/start my instance to move it to another cluster.  Of course, this resulted in the ACC having a different public IP and public FQDN.

No problem, as I already had created a CNAME entry in public DNS for acc3.mydomain.com.  I updated that with the new Amazon FQDN, but still had no joy in my Astaro, even today, several days after the change!  I realized that I hadn't changed the entry in my internal DNS (see DNS Best Practice).  Once I had changed that and flushed the caches both there and on the Astaro, ping from 'Support >> Tools' gave the correct result for acc3.mydomain.com.

However, nothing changed for the DNS host definition.  I opened in and saved it - still the old address.

Finally, I created a new DNS Host definition using acc3.mydomain.com.  As soon as confd finished displaying the new definition, I saw that the old definition had updated.  I suspect that this behavior has existed for awhile.

Cheers - Bob
  • 0 
    Astaro Beta Report
    --------------------------------
    Version: 8.285
    Type: BUG
    State: MERGED/FIXED
    Reporter: BAlfson
    Contributor: 
    MantisID: 19696
    Target version: 8.810
    Fixed in version: 8.810
    --------------------------------

  • 0
    Can you find anything useful in system.log?
    All dns-resolver output goes there.

    What is the TTL of your DNS name?

    Cheers
     Ulrich
  • 0
    Interesting.  The syslog seems to have lines from two different places, with rsyslog lines being delayed from a bit over 2 hours to a bit less than three hours.  The fifth and sixth lines today are:

    2011:11:29-00:00:08 astaro postgres[23033]: [3-1] LOG:  unexpected EOF on client connection
    2011:11:28-20:22:57 astaro rsyslog: action 3 queue[DA]: size=0 enqueued=23061 full=22749 maxqsize=1251



    Outside of that seeming anomaly, there's nothing other than cron jobs for reporting during the time I was doing the above test.

    Standard public TTLs for our domain are 14400, but the problem is that I was in 'Support >> Tools', pinged acc3.mydomain.com and got the correct answer, yet got an incorrect answer when I pinged the pre-defined DNS Host definition.

    Why wouldn't the host definiton ask for resolution after I had flushed the DNS cache on the Astaro?  Plainly, this is an issue with WebAdmin as the tool asked for resolution of the FQDN when I entered that directly.  Shouldn't flushing the DNS cache force the TTLs to zero for DNS Hosts?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Dont know if this is related, but I have noticed this - but dont know if it was there before the beta as well 

    2011:11:29-11:59:47 asg220_silk named[5852]: loading configuration from '//etc/named.conf'

    2011:11:29-11:59:47 asg220_silk named[5852]: no IPv6 interfaces found

    2011:11:29-11:59:47 asg220_silk named[5852]: listening on IPv4 interface redc1, 10.230.230.2#53

    2011:11:29-11:59:47 asg220_silk named[5852]: reloading configuration succeeded

    2011:11:29-11:59:47 asg220_silk named[5852]: zone 0.IN-ADDR.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone 127.IN-ADDR.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone 254.169.IN-ADDR.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone 2.0.192.IN-ADDR.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone 100.51.198.IN-ADDR.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone 113.0.203.IN-ADDR.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone 255.255.255.255.IN-ADDR.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone 8.B.D.0.1.0.0.2.IP6.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone D.F.IP6.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone 8.E.F.IP6.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone 9.E.F.IP6.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone A.E.F.IP6.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: zone B.E.F.IP6.ARPA/IN: zone serial unchanged. zone may fail to transfer to slaves.

    2011:11:29-11:59:47 asg220_silk named[5852]: reloading zones succeeded


    and alot of these 

    2011:11:29-13:41:11 asg220_silk named[5852]: unexpected RCODE (REFUSED) resolving '105.71.245.173.in-addr.arpa/PTR/IN': 72.13.80.2#53

    2011:11:29-13:41:11 asg220_silk named[5852]: unexpected RCODE (REFUSED) resolving '105.71.245.173.in-addr.arpa/PTR/IN': 72.13.81.2#53

    2011:11:29-13:41:12 asg220_silk named[5852]: unexpected RCODE (REFUSED) resolving '105.71.245.173.in-addr.arpa/PTR/IN': 72.13.80.2#53


    If its not related, please disregard this or delete the post.
  • 0 in reply to BAlfson
    Interesting problem you have there Bob. However you are killing me with 14400 default TTL setting[:D] Make that dns work and set it 10-20 minutes and live on the wild side[;)] 

    Only dns hosts I have (facebook etc)have very short TTLs so usually don't see the problem you are having.

    By the way I have many EOF errors, I still don't know what them[:S]
    gatekeeper:/var/log # tail -100 system.log |grep EOF
    2011:11:29-16:23:29 gatekeeper postgres[8984]: [2-1] LOG:  unexpected EOF on client connection
    2011:11:29-17:04:46 gatekeeper postgres[10946]: [2-1] LOG:  unexpected EOF on client connection
    2011:11:29-17:41:09 gatekeeper postgres[12634]: [2-1] LOG:  unexpected EOF on client connection


    Regards
    Bill
  • 0
    Please guys, don't post totally unrelated logs. I was interested in "dns-resolver" program logging to system.log.

    dns-resolver will resolve DNS names after the TTL expires. However it makes sense, to flush
    the DNS resolver after you flush the DNS cache too. Will open an ID for that...

    Cheers
     Ulrich
  • 0 in reply to da_merlin
    Please guys, don't post totally unrelated logs. I was interested in "dns-resolver" program logging to system.log.

    Sorry about that Ulrich, just having some fun with Bob. I don't have OP problem so can't add anything else constructive to this conversation.

    Regards
    Bill
Cookie Information Banner