initial DNS zone transfer too slow, too slow to update, any configuration to speed it up?
Clash Royale CLAN TAG#URR8PPP
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
|
show 7 more comments
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
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 runrndc
when you change the data, but I haven't usedbind
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
|
show 7 more comments
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
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
dns vmware
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 runrndc
when you change the data, but I haven't usedbind
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
|
show 7 more comments
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 runrndc
when you change the data, but I haven't usedbind
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
|
show 7 more comments
1 Answer
1
active
oldest
votes
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.
Good job. Though supposedly BIND has algorithms to prevent this...
– Rui F Ribeiro
Jan 1 at 15:35
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
Good job. Though supposedly BIND has algorithms to prevent this...
– Rui F Ribeiro
Jan 1 at 15:35
add a comment |
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.
Good job. Though supposedly BIND has algorithms to prevent this...
– Rui F Ribeiro
Jan 1 at 15:35
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 runrndc
when you change the data, but I haven't usedbind
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