[7.460][BUG][CONFIRMED] DNS Cache not flushed when adding or removing a forwarder

[Billybob]

When you make configuration changes to dns, the bind configuration is reloaded and bind is not restarted. It is fine when adding or removing allowed networks etc but bind should be restarted/cache flushed specially when an old forwarder is deleted for security reasons.

[utm_kid]

Originally Posted by Billybob

When you make configuration changes to dns, the bind configuration is reloaded and bind is not restarted. It is fine when adding or removing allowed networks etc but bind should be restarted/cache flushed specially when an old forwarder is deleted for security reasons.

hello Sir,

And after delete and adding new DNS forwarder try to traceroute with traceroute see the what kind of output u r getting and old name remain same but changed ip (new name doesn't show it )

Thanks

[Astaro Beta Bot]

Astaro Beta Report
--------------------------------
Version: 7.460
Type: BUG
State: CONFIRMED
Reporter: Billybob
Contributor: 
MantisID: 10783
--------------------------------

[utm_kid]

Originally Posted by Astaro Beta Bot

Astaro Beta Report
--------------------------------
Version: 7.460
Type: BUG
State: OPEN
Reporter: Billybob
Contributor: 
MantisID: 
--------------------------------

Sir, can u pls try with this

/var/mdw/scripts/named restart

i think it fixed my problem
Thanks

[BAlfson]

That's what Billybob was describing. I guess that your CLI instruction is what happens when one presses the [Flush resolver cache now] on the 'Global' tab of DNS.

Cheers - Bob

[Billybob]

You got it bob, bind by default flushes dns cache when restarted unlike windows dns. So the big button in astaro that says flush cache is just restarting bind in reality

[utm_kid]

Originally Posted by Billybob

You got it bob, bind by default flushes dns cache when restarted unlike windows dns. So the big button in astaro that says flush cache is just restarting bind in reality

when u run from webadmin>>flush

automatic empty zone: B.E.F.IP6.ARPA
2009:06:29-08:36:09 ace75 named[5482]: default max-cache-size (33554432) applies: view _bind
2009:06:29-08:36:09 ace75 named[5482]: none:0: open: //etc/rndc.key: file not found

i test/run this command some time back but that time i didn't get error

After u delete then name from dns forwarder that old entry with old name remain same with tools>>traceroute and when u traceroute u will get very wage output of traceroute ,new dns forwarder ip doesnt come in to traceroute field it remain old which u confiure while inital config

Dns>>forwarder>>when u delete old name and add new name still it says added by installation wizard in facet i add that after 8 days or so after delete the orignal one

Thanks

[BAlfson]

Yes, that seems consistent.

[utm_kid]

Originally Posted by BAlfson

Yes, that seems consistent.

Hello Sir,


2009:06:29-17:46:11 ace75 named[7430]: automatic empty zone: 8.E.F.IP6.ARPA
2009:06:29-17:46:11 ace75 named[7430]: automatic empty zone: 9.E.F.IP6.ARPA
2009:06:29-17:46:11 ace75 named[7430]: automatic empty zone: A.E.F.IP6.ARPA
2009:06:29-17:46:11 ace75 named[7430]: automatic empty zone: B.E.F.IP6.ARPA
2009:06:29-17:46:11 ace75 named[7430]: default max-cache-size (33554432) applies: view _bind
2009:06:29-17:46:11 ace75 named[7430]: none:0: open: //etc/rndc.key: file not found
2009:06:29-17:46:11 ace75 named[7430]: couldn't add command channel 127.0.0.1#953: file not found
2009:06:29-17:46:11 ace75 named[7430]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1246275400
2009:06:29-17:46:11 ace75 named[7430]: zone localhost/IN: loaded serial 1246275400
2009:06:29-17:46:11 ace75 named[7430]: running

how do i check current dns flash status like in windows we run ipconfig/displaydns

# which rndc
/usr/sbin/rndc
ace75:/var/mdw/scripts # /usr/sbin/rndc status
rndc: neither /etc/rndc.conf nor /etc/rndc.key was found
ace75:/var/mdw/scripts # /usr/sbin/rndc /?
rndc: neither /etc/rndc.conf nor /etc/rndc.key was found
ace75:/var/mdw/scripts # /usr/sbin/rndc --help
/usr/sbin/rndc: illegal option -- -
Usage: rndc [-c config] [-s server] [-p port]
[-k key-file ] [-y key] [-V] command

command is one of the following:

reload Reload configuration file and zones.
reload zone [class [view]]
Reload a single zone.
refresh zone [class [view]]
Schedule immediate maintenance for a zone.
retransfer zone [class [view]]
Retransfer a single zone without checking serial number.
freeze zone [class [view]]
Suspend updates to a dynamic zone.
thaw zone [class [view]]
Enable updates to a frozen dynamic zone and reload it.
reconfig Reload configuration file and new zones only.
stats Write server statistics to the statistics file.
querylog Toggle query logging.
dumpdb [-all|-cache|-zones] [view ...]
Dump cache(s) to the dump file (named_dump.db).
stop Save pending updates to master files and stop the server.
stop -p Save pending updates to master files and stop the server
reporting process id.
halt Stop the server without saving pending updates.
halt -p Stop the server without saving pending updates reporting
process id.
trace Increment debugging level by one.
trace level Change the debugging level.
notrace Set debugging level to 0.
flush Flushes all of the server's caches.
flush [view] Flushes the server's cache for a view.
flushname name [view]
Flush the given name from the server's cache(s)
status Display status of the server.
recursing Dump the queries that are currently recursing (named.recursing)
*restart Restart the server.

* == not yet implemented
Version: 9.3.2
ace75:/var/mdw/scripts # /usr/sbin/rndc flush
rndc: neither /etc/rndc.conf nor /etc/rndc.key was found
ace75:/var/mdw/scripts #


Thanks

[Billybob]

You are getting too technical here. Ipconfig /displaydns displays the cache on a windows machine not running a dns server. Those are cached queries by the OS not the same as a dns server cache.

You are on the right track trying to run rndc dumpdb but middleware handles all proxies on astaro so rndc is not implemented.

As bob has pointed out before, our job as beta testers is to find errors with webadmin. If you can dig deeper a little just to clarify the error, thats great but digging too far is counter productive.

We have identified the error and the cause, now lets see if astaro folks agree with us and fix it in the next release