initial DNS zone transfer too slow, too slow to update, any configuration to speed it up?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












1















I have configured a master/Slave zone, the initial zone transfer is too slow and no changes have happened over the course of 10 mins, the only update I have seen so far is 2 updates, this is in a test VMs and not production, there is hardly any data in it. Could it be a misconfiguration, I have changed TTL, refresh, retry to 100, yet nothing happens, tried bumping up the serial as well to get an update, no change. The first time I got it working it was quicker, now I repeated the same setup with a new IP and it's too slow. I have read this and have added it in my zone files as well, still it's dead slow.



Forward Zone



$TTL 3H
$ORIGIN L00144445.local.

@ IN SOA ns1.L00144445.local. admin.L00144445.local. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns1.L00144445.local.

IN NS ns2.L00144445.local.

ns1 IN A 192.168.102.191

ns2 IN A 192.168.102.192


Reverse Zone



$TTL 3H
$ORIGIN 102.168.192.IN-ADDR.ARPA.

@ IN SOA ns1.L00144445.local. admin.L00144445.local. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns1.L00144445.local.

IN NS ns2.L00144445.local.

191 IN PTR ns1.L00144445.local.

192 IN PTR ns2.L00144445.local.


Anything else I should do to speed up the initial update ?










share|improve this question






















  • It took about 30 minutes to complete the zone update, if someone could explain what happens in the background that takes this much time, that would be great..

    – Huud Rych
    Dec 31 '18 at 23:00











  • It would help to say which dns software you are using. After that you should say what commands you run after you update the master to encourage the slave to get the updated data.

    – icarus
    Dec 31 '18 at 23:13











  • Sorry didnt realize that, I'm using the BIND v9, the command to update is named -u named -g -p 53 to get the Slave to update..

    – Huud Rych
    Dec 31 '18 at 23:15












  • named -u named -g -p 53 runs the named command in the foreground. My understanding is these days you want to run rndc when you change the data, but I haven't used bind in decades.

    – icarus
    Dec 31 '18 at 23:20






  • 1





    Did you change the serial number before you did the reload?

    – icarus
    Dec 31 '18 at 23:32















1















I have configured a master/Slave zone, the initial zone transfer is too slow and no changes have happened over the course of 10 mins, the only update I have seen so far is 2 updates, this is in a test VMs and not production, there is hardly any data in it. Could it be a misconfiguration, I have changed TTL, refresh, retry to 100, yet nothing happens, tried bumping up the serial as well to get an update, no change. The first time I got it working it was quicker, now I repeated the same setup with a new IP and it's too slow. I have read this and have added it in my zone files as well, still it's dead slow.



Forward Zone



$TTL 3H
$ORIGIN L00144445.local.

@ IN SOA ns1.L00144445.local. admin.L00144445.local. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns1.L00144445.local.

IN NS ns2.L00144445.local.

ns1 IN A 192.168.102.191

ns2 IN A 192.168.102.192


Reverse Zone



$TTL 3H
$ORIGIN 102.168.192.IN-ADDR.ARPA.

@ IN SOA ns1.L00144445.local. admin.L00144445.local. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns1.L00144445.local.

IN NS ns2.L00144445.local.

191 IN PTR ns1.L00144445.local.

192 IN PTR ns2.L00144445.local.


Anything else I should do to speed up the initial update ?










share|improve this question






















  • It took about 30 minutes to complete the zone update, if someone could explain what happens in the background that takes this much time, that would be great..

    – Huud Rych
    Dec 31 '18 at 23:00











  • It would help to say which dns software you are using. After that you should say what commands you run after you update the master to encourage the slave to get the updated data.

    – icarus
    Dec 31 '18 at 23:13











  • Sorry didnt realize that, I'm using the BIND v9, the command to update is named -u named -g -p 53 to get the Slave to update..

    – Huud Rych
    Dec 31 '18 at 23:15












  • named -u named -g -p 53 runs the named command in the foreground. My understanding is these days you want to run rndc when you change the data, but I haven't used bind in decades.

    – icarus
    Dec 31 '18 at 23:20






  • 1





    Did you change the serial number before you did the reload?

    – icarus
    Dec 31 '18 at 23:32













1












1








1








I have configured a master/Slave zone, the initial zone transfer is too slow and no changes have happened over the course of 10 mins, the only update I have seen so far is 2 updates, this is in a test VMs and not production, there is hardly any data in it. Could it be a misconfiguration, I have changed TTL, refresh, retry to 100, yet nothing happens, tried bumping up the serial as well to get an update, no change. The first time I got it working it was quicker, now I repeated the same setup with a new IP and it's too slow. I have read this and have added it in my zone files as well, still it's dead slow.



Forward Zone



$TTL 3H
$ORIGIN L00144445.local.

@ IN SOA ns1.L00144445.local. admin.L00144445.local. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns1.L00144445.local.

IN NS ns2.L00144445.local.

ns1 IN A 192.168.102.191

ns2 IN A 192.168.102.192


Reverse Zone



$TTL 3H
$ORIGIN 102.168.192.IN-ADDR.ARPA.

@ IN SOA ns1.L00144445.local. admin.L00144445.local. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns1.L00144445.local.

IN NS ns2.L00144445.local.

191 IN PTR ns1.L00144445.local.

192 IN PTR ns2.L00144445.local.


Anything else I should do to speed up the initial update ?










share|improve this question














I have configured a master/Slave zone, the initial zone transfer is too slow and no changes have happened over the course of 10 mins, the only update I have seen so far is 2 updates, this is in a test VMs and not production, there is hardly any data in it. Could it be a misconfiguration, I have changed TTL, refresh, retry to 100, yet nothing happens, tried bumping up the serial as well to get an update, no change. The first time I got it working it was quicker, now I repeated the same setup with a new IP and it's too slow. I have read this and have added it in my zone files as well, still it's dead slow.



Forward Zone



$TTL 3H
$ORIGIN L00144445.local.

@ IN SOA ns1.L00144445.local. admin.L00144445.local. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns1.L00144445.local.

IN NS ns2.L00144445.local.

ns1 IN A 192.168.102.191

ns2 IN A 192.168.102.192


Reverse Zone



$TTL 3H
$ORIGIN 102.168.192.IN-ADDR.ARPA.

@ IN SOA ns1.L00144445.local. admin.L00144445.local. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns1.L00144445.local.

IN NS ns2.L00144445.local.

191 IN PTR ns1.L00144445.local.

192 IN PTR ns2.L00144445.local.


Anything else I should do to speed up the initial update ?







dns vmware






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Dec 31 '18 at 22:40









Huud RychHuud Rych

215




215












  • It took about 30 minutes to complete the zone update, if someone could explain what happens in the background that takes this much time, that would be great..

    – Huud Rych
    Dec 31 '18 at 23:00











  • It would help to say which dns software you are using. After that you should say what commands you run after you update the master to encourage the slave to get the updated data.

    – icarus
    Dec 31 '18 at 23:13











  • Sorry didnt realize that, I'm using the BIND v9, the command to update is named -u named -g -p 53 to get the Slave to update..

    – Huud Rych
    Dec 31 '18 at 23:15












  • named -u named -g -p 53 runs the named command in the foreground. My understanding is these days you want to run rndc when you change the data, but I haven't used bind in decades.

    – icarus
    Dec 31 '18 at 23:20






  • 1





    Did you change the serial number before you did the reload?

    – icarus
    Dec 31 '18 at 23:32

















  • It took about 30 minutes to complete the zone update, if someone could explain what happens in the background that takes this much time, that would be great..

    – Huud Rych
    Dec 31 '18 at 23:00











  • It would help to say which dns software you are using. After that you should say what commands you run after you update the master to encourage the slave to get the updated data.

    – icarus
    Dec 31 '18 at 23:13











  • Sorry didnt realize that, I'm using the BIND v9, the command to update is named -u named -g -p 53 to get the Slave to update..

    – Huud Rych
    Dec 31 '18 at 23:15












  • named -u named -g -p 53 runs the named command in the foreground. My understanding is these days you want to run rndc when you change the data, but I haven't used bind in decades.

    – icarus
    Dec 31 '18 at 23:20






  • 1





    Did you change the serial number before you did the reload?

    – icarus
    Dec 31 '18 at 23:32
















It took about 30 minutes to complete the zone update, if someone could explain what happens in the background that takes this much time, that would be great..

– Huud Rych
Dec 31 '18 at 23:00





It took about 30 minutes to complete the zone update, if someone could explain what happens in the background that takes this much time, that would be great..

– Huud Rych
Dec 31 '18 at 23:00













It would help to say which dns software you are using. After that you should say what commands you run after you update the master to encourage the slave to get the updated data.

– icarus
Dec 31 '18 at 23:13





It would help to say which dns software you are using. After that you should say what commands you run after you update the master to encourage the slave to get the updated data.

– icarus
Dec 31 '18 at 23:13













Sorry didnt realize that, I'm using the BIND v9, the command to update is named -u named -g -p 53 to get the Slave to update..

– Huud Rych
Dec 31 '18 at 23:15






Sorry didnt realize that, I'm using the BIND v9, the command to update is named -u named -g -p 53 to get the Slave to update..

– Huud Rych
Dec 31 '18 at 23:15














named -u named -g -p 53 runs the named command in the foreground. My understanding is these days you want to run rndc when you change the data, but I haven't used bind in decades.

– icarus
Dec 31 '18 at 23:20





named -u named -g -p 53 runs the named command in the foreground. My understanding is these days you want to run rndc when you change the data, but I haven't used bind in decades.

– icarus
Dec 31 '18 at 23:20




1




1





Did you change the serial number before you did the reload?

– icarus
Dec 31 '18 at 23:32





Did you change the serial number before you did the reload?

– icarus
Dec 31 '18 at 23:32










1 Answer
1






active

oldest

votes


















1














I found the problem to be ipv6 configuration which kept on attempting to update the zones as well, this was found in /var/log/messages log file, and since it was pre-configured in its default setting, it would keep on attempting to update zone right after ipv4 is updated thus no response was even received.



Removed all references of ipv6 from /etc/named.conf, and added the following options to /etc/sysonfig/named file.



RESOLVCONF=yes



OPTIONS=-4



Now it updates instantly.






share|improve this answer

























  • Good job. Though supposedly BIND has algorithms to prevent this...

    – Rui F Ribeiro
    Jan 1 at 15:35










Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f491833%2finitial-dns-zone-transfer-too-slow-too-slow-to-update-any-configuration-to-spe%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














I found the problem to be ipv6 configuration which kept on attempting to update the zones as well, this was found in /var/log/messages log file, and since it was pre-configured in its default setting, it would keep on attempting to update zone right after ipv4 is updated thus no response was even received.



Removed all references of ipv6 from /etc/named.conf, and added the following options to /etc/sysonfig/named file.



RESOLVCONF=yes



OPTIONS=-4



Now it updates instantly.






share|improve this answer

























  • Good job. Though supposedly BIND has algorithms to prevent this...

    – Rui F Ribeiro
    Jan 1 at 15:35















1














I found the problem to be ipv6 configuration which kept on attempting to update the zones as well, this was found in /var/log/messages log file, and since it was pre-configured in its default setting, it would keep on attempting to update zone right after ipv4 is updated thus no response was even received.



Removed all references of ipv6 from /etc/named.conf, and added the following options to /etc/sysonfig/named file.



RESOLVCONF=yes



OPTIONS=-4



Now it updates instantly.






share|improve this answer

























  • Good job. Though supposedly BIND has algorithms to prevent this...

    – Rui F Ribeiro
    Jan 1 at 15:35













1












1








1







I found the problem to be ipv6 configuration which kept on attempting to update the zones as well, this was found in /var/log/messages log file, and since it was pre-configured in its default setting, it would keep on attempting to update zone right after ipv4 is updated thus no response was even received.



Removed all references of ipv6 from /etc/named.conf, and added the following options to /etc/sysonfig/named file.



RESOLVCONF=yes



OPTIONS=-4



Now it updates instantly.






share|improve this answer















I found the problem to be ipv6 configuration which kept on attempting to update the zones as well, this was found in /var/log/messages log file, and since it was pre-configured in its default setting, it would keep on attempting to update zone right after ipv4 is updated thus no response was even received.



Removed all references of ipv6 from /etc/named.conf, and added the following options to /etc/sysonfig/named file.



RESOLVCONF=yes



OPTIONS=-4



Now it updates instantly.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 1 at 17:46

























answered Jan 1 at 12:33









Huud RychHuud Rych

215




215












  • Good job. Though supposedly BIND has algorithms to prevent this...

    – Rui F Ribeiro
    Jan 1 at 15:35

















  • Good job. Though supposedly BIND has algorithms to prevent this...

    – Rui F Ribeiro
    Jan 1 at 15:35
















Good job. Though supposedly BIND has algorithms to prevent this...

– Rui F Ribeiro
Jan 1 at 15:35





Good job. Though supposedly BIND has algorithms to prevent this...

– Rui F Ribeiro
Jan 1 at 15:35

















draft saved

draft discarded
















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f491833%2finitial-dns-zone-transfer-too-slow-too-slow-to-update-any-configuration-to-spe%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?