Re: new bind 9.9 and root NS
-Original Message-
From: dkole...@olearycomputers.com dkole...@olearycomputers.com
Organization: http://groups.google.com
Date: Tuesday, July 31, 2012 2:16 PM
To: comp-protocols-dns-b...@isc.org comp-protocols-dns-b...@isc.org
Subject: new bind 9.9 and root NS
I have a client who's migrating from an old bind 9.3 installation to a
new bind 9.9. I've done the migration and everything seemed to be
running fine. Before switching the internic pointers, though, the
client gave it a good thorough trashing and they're finding some
issues.
On the new system, the first time a domain outside of the client's
authoritative space is queried, the response takes longer than it
should. Obviously, non-cached searches will take longer, but these
are taking *way* longer:
# rndc flush
# time host www.olearycomputers.com.
www.olearycomputers.com has address 69.246.199.78
real 0m7.62s
user 0m0.00s
sys 0m0.00s
The old server beats that by more than 3 seconds:
[root]# rndc flush
[root]# time host www.olearycomputers.com.
www.olearycomputers.com has address 69.246.199.78
real 0m3.334s
user 0m0.003s
sys 0m0.003s
This almost sounds like an upstream firewall or proxy with faulty protocol
fixups. If you do a query and EDNS is blocked or improperly configured
a fall back will occur which causes queries to take longer or possibly
timeout.
A dig trace on the old box looks resonable:
# dig +trace www.olearycomputers.com
; DiG 9.3.4 +trace www.olearycomputers.com
;; global options: printcmd
[[root ns snipped]]
;; Received 512 bytes from 143.43.32.201#53(143.43.32.201) in 1 ms
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
[[remaining .com NS snipped]]
;; Received 501 bytes from 192.5.5.241#53(f.root-servers.net) in 71 ms
olearycomputers.com. 172800 IN NS ns3.no-ip.com.
olearycomputers.com. 172800 IN NS ns1.no-ip.com.
olearycomputers.com. 172800 IN NS ns4.no-ip.com.
olearycomputers.com. 172800 IN NS ns5.no-ip.com.
;; Received 211 bytes from 192.35.51.30#53(f.gtld-servers.net) in 77
ms
www.olearycomputers.com. 60 IN A 69.246.199.78
olearycomputers.com. 86400 IN NS ns5.no-ip.com.
[[etc]]
;; Received 289 bytes from 204.16.253.33#53(ns3.no-ip.com) in 34 ms
On the new box, I get nowhere:
# dig +trace www.olearycomputers.com
; DiG 9.9.1-P1-RedHat-9.9.1-2.P1.fc17 +trace
www.olearycomputers.com
;; global options: +cmd
. 517932 IN NS g.root-servers.net.
. 517932 IN NS e.root-servers.net.
[[some root ns snipped]]
518025 IN RRSIG NS 8 0 518400 2012080700 2012073023 50398 .
ICR2HkAQdy85QN3+i3lpLqoFc11zE/ZTNiBcb9F6dyglatHsX+dvWdJS 1laG5xA//M/
OfFCALDy/xApk/Thnh20mTeEtXiiB0IEBFE17B3NgTggO gqbhk7sWt0m7SyDbXgHLbbFB
+xyLMbT3bOaUUVf7470Cnx6eTI8Q5Hco PVs=
;; Received 857 bytes from 143.43.32.170#53(143.43.32.170) in 5 ms
;; connection timed out; no servers could be reached
A straight hit to one of the root ns on the new box is equally as bad:
# dig @a.root-servers.net.
; DiG 9.9.1-P1-RedHat-9.9.1-2.P1.fc17 @a.root-servers.net.
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
But, on the old box works like a champ:
# ssh ${old} 'dig @a.root-servers.net.'
; DiG 9.3.4 @a.root-servers.net.
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 1160
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
[[sniped]]
;; Query time: 25 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Tue Jul 31 15:50:47 2012
;; MSG SIZE rcvd: 512
Can someone tell me why the root ns don't seem to like the new bind
9.9 systems?
Since it's a new IP, are you sure ACLs are allowing any to 53/tcp and
53/udp on your new name server and from your name server to any on the
same ports?
What are you seeing in named's logs?
https://kb.isc.org/article/AA-00708/55/Why-does-BIND-log-messages-about-dis
abling-EDNS-or-reducing-the-advertised-packet-size
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: new bind 9.9 and root NS
On 08/05/2012 23:05, Michael Hoskins (michoski) wrote: This almost sounds like an upstream firewall or proxy with faulty protocol fixups. If you do a query and EDNS is blocked or improperly configured a fall back will occur which causes queries to take longer or possibly timeout. +1 https://www.dns-oarc.net/oarc/services/replysizetest -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delayed Zone Transfers?
From: J b...@namor.ca To: bind-users@lists.isc.org bind-users@lists.isc.org Cc: Sent: Thursday, August 2, 2012 5:57 PM Subject: Re: Delayed Zone Transfers? Jiann-Ming Su wrote: What would cause a delay in zone transfers? The notify go out immediately when the serial number changes on the master, but some of the secondaries can take up to 10 minutes before initiating the zone transfer. Also, even after the zone has been transferred, the secondary will not immediately serve out the new data. I'm running 9.8.1-P1, soon to be 9.8.3-P2. Thanks for any insights. A large backlog of zone transfers on the slave? I don't think that's the case for mine. Here's an example of a 14 minute delay after receiving a notify: 06-Aug-2012 11:20:36.575 notify: client 192.168.8.8#33456: view hc: received notify for zone 'uts-sa.mydomain.ddns': TSIG 'dns1.mydomain.org' 06-Aug-2012 11:34:36.177 general: zone uts-sa.mydomain.ddns/IN/all: Transfer started. 06-Aug-2012 11:34:36.178 xfer-in: transfer of 'uts-sa.mydomain.ddns/IN' from 192.168.8.8#53: connected using 192.168.96.100#49189 06-Aug-2012 11:34:36.184 general: zone uts-sa.mydomain.ddns/IN/all: transferred serial 2010585436: TSIG 'dns1.mydomain.org' 06-Aug-2012 11:34:36.184 xfer-in: transfer of 'uts-sa.mydomain.ddns/IN' from 192.168.8.8#53: end of transfer 06-Aug-2012 11:34:36.185 notify: zone uts-sa.mydomain.ddns/IN/all: sending notifies (serial 2010585436) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delayed Zone Transfers?
From: Jiann-Ming Su su_...@yahoo.com To: bind-users@lists.isc.org bind-users@lists.isc.org Cc: Sent: Thursday, August 2, 2012 5:38 PM Subject: Delayed Zone Transfers? What would cause a delay in zone transfers? The notify go out immediately when the serial number changes on the master, but some of the secondaries can take up to 10 minutes before initiating the zone transfer. Also, even after the zone has been transferred, the secondary will not immediately serve out the new data. I'm running 9.8.1-P1, soon to be 9.8.3-P2. Thanks for any insights. Here's an example of the zone file being updated, but BIND not serving out the new data. Running dig locally: # dig @localhost myhost.uts-sa.mydomain.ddns ; DiG 9.8.3-P2 @localhost myhost.uts-sa.mydomain.ddns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 36470 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;myhost.uts-sa.mydomain.ddns. IN A ;; AUTHORITY SECTION: uts-sa.mydomain.ddns. 86400 IN SOA dhcp-admin.service.mydomain.net. hostmaster.mydomain.net. 2010585436 7200 1800 604800 86400 ;; Query time: 6 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Aug 6 11:53:45 2012 ;; MSG SIZE rcvd: 118 Contents of the local zone file: # less ddb.uts-sa.mydomain.ddns $ORIGIN . $TTL 86400 ; 1 day uts-sa.mydomain.ddns IN SOA dhcp-admin.service.mydomain.net. hostmaster.mydomain.net. ( 2010585437 ; serial 7200 ; refresh (2 hours) 1800 ; retry (30 minutes) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS dns1.mydomain.net. NS dns2.mydomain.net. $ORIGIN uts-sa.mydomain.ddns. $TTL 7200 ; 2 hours myhost A 10.231.24.252 TXT 00e9e034c52bb28952e1b7192519421cc5 The SOA that it's serving is not the newest one. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delayed Zone Transfers?
On 06/08/12 17:03, Jiann-Ming Su wrote: Here's an example of the zone file being updated, but BIND not serving out the new data. Running dig locally: # dig @localhost myhost.uts-sa.mydomain.ddns I note from your other email that you are using views. Are you sure you are querying the right view? It seems that you may be querying the view in which the zone is not slaved, hence you get old, cached data. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multi-master DNS with Bind
On Aug 5, 2012, at 11:26 PM, Evan Hunt wrote: Looking to find information as to whether I can set up bind for multi-master DNS. I want to be able to update DNS records via any or more than one nameserver in the domain and have the records updated and propagated regardless if the master is available. Is this supported or are there ways to make this work with bind? Not at this time. We've discussed the subject at some length and it may appear in a future release, but it's not on the near-term roadmap. Couldn't this be done with DLZ? signature.asc Description: Message signed with OpenPGP using GPGMail ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delayed Zone Transfers?
From: Phil Mayers p.may...@imperial.ac.uk
To: bind-users@lists.isc.org
Cc:
Sent: Monday, August 6, 2012 12:07 PM
Subject: Re: Delayed Zone Transfers?
On 06/08/12 17:03, Jiann-Ming Su wrote:
Here's an example of the zone file being updated, but BIND not serving
out the new data.
Running dig locally:
# dig @localhost myhost.uts-sa.mydomain.ddns
I note from your other email that you are using views.
Are you sure you are querying the right view? It seems that you may be
querying
the view in which the zone is not slaved, hence you get old, cached data.
Yeah, I've wondered about views. We went to views to work around a MTA config
issue. The weird zone transfer performance seem to have coincided with our
transition to views. Here's my named.conf, FWIW:
view hc {
match-clients { 192.168.0.0/16; 10.236.0.0/16; };
match-destinations { any; };
include /etc/named.zones;
zone s7a1.psmtp.com {
type slave;
file db.postini-s7a1;
masters { dnsmgr; };
};
zone s7a2.psmtp.com {
type slave;
file db.postini-s7a2;
masters { dnsmgr; };
};
zone s7b1.psmtp.com {
type slave;
file db.postini-s7b1;
masters { dnsmgr; };
};
zone s7b2.psmtp.com {
type slave;
file db.postini-s7b2;
masters { dnsmgr; };
};
};
view all {
match-clients { any; };
match-destinations { any; };
include /etc/named.zones;
};
For the particular case I demonstrated in the previous email, I don't think
views should have affected it as the default all view should have been hit.
And even the hc view, the data would be the same as we're only spoofing for
the specific psmtp.com mail hosts.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Multi-master DNS with Bind
Don't know. I haven't used it. Do you have experience with it? From: Chris Buxton chris.p.bux...@gmail.com To: Evan Hunt e...@isc.org, Cc: john.debe...@teradyne.com, bind-users@lists.isc.org Date: 08/06/2012 12:13 PM Subject:Re: Multi-master DNS with Bind On Aug 5, 2012, at 11:26 PM, Evan Hunt wrote: Looking to find information as to whether I can set up bind for multi-master DNS. I want to be able to update DNS records via any or more than one nameserver in the domain and have the records updated and propagated regardless if the master is available. Is this supported or are there ways to make this work with bind? Not at this time. We've discussed the subject at some length and it may appear in a future release, but it's not on the near-term roadmap. Couldn't this be done with DLZ? [attachment signature.asc deleted by John DeBella/Bos/Teradyne]inline: graycol.gif___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delayed Zone Transfers?
From: Jiann-Ming Su su_...@yahoo.com
To: bind-users@lists.isc.org bind-users@lists.isc.org
Cc:
Sent: Monday, August 6, 2012 12:33 PM
Subject: Re: Delayed Zone Transfers?
From: Phil Mayers p.may...@imperial.ac.uk
To: bind-users@lists.isc.org
Cc:
Sent: Monday, August 6, 2012 12:07 PM
Subject: Re: Delayed Zone Transfers?
On 06/08/12 17:03, Jiann-Ming Su wrote:
Here's an example of the zone file being updated, but BIND not
serving
out the new data.
Running dig locally:
# dig @localhost myhost.uts-sa.mydomain.ddns
I note from your other email that you are using views.
Are you sure you are querying the right view? It seems that you may be
querying
the view in which the zone is not slaved, hence you get old, cached data.
Yeah, I've wondered about views. We went to views to work around a MTA
config issue. The weird zone transfer performance seem to have coincided
with
our transition to views. Here's my named.conf, FWIW:
view hc {
match-clients { 192.168.0.0/16; 10.236.0.0/16; };
match-destinations { any; };
include /etc/named.zones;
zone s7a1.psmtp.com {
type slave;
file db.postini-s7a1;
masters { dnsmgr; };
};
zone s7a2.psmtp.com {
type slave;
file db.postini-s7a2;
masters { dnsmgr; };
};
zone s7b1.psmtp.com {
type slave;
file db.postini-s7b1;
masters { dnsmgr; };
};
zone s7b2.psmtp.com {
type slave;
file db.postini-s7b2;
masters { dnsmgr; };
};
};
view all {
match-clients { any; };
match-destinations { any; };
include /etc/named.zones;
};
For the particular case I demonstrated in the previous email, I don't think
views should have affected it as the default all view should have
been hit. And even the hc view, the data would be the same as
we're only spoofing for the specific psmtp.com mail hosts.
Interestingly, for the one secondary caching old data, it actually did an IXFR
as soon as it was notified by the master that the zone had updated.
Aug 06 11:20:35.067 notify: received notify for zone 'uts-sa.mydomain.ddns'
Aug 06 11:20:35.078 notify: zone uts-sa.mydomain.ddns/IN: sending notifies
(serial 2010585437)
Aug 06 11:20:36.083 xfer-out: client 10.140.51.162#51088: transfer of
'uts-sa.mydomain.ddns/IN': IXFR started
However, I just did a rndc reload on that zone, and it did a full AXFR:
Aug 06 12:43:35.320 xfer-out: client 10.140.51.162#40496: transfer of
'uts-sa.emory.ddns/IN': AXFR-style IXFR started
After this, it is now serving out fresh data.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Delayed Zone Transfers
.
hostmaster.mydomain.net. (
??? 2010585437 ; serial
??? 7200?? ; refresh (2 hours)
??? 1800?? ; retry (30 minutes)
??? 604800 ; expire (1 week)
??? 86400? ; minimum (1 day)
??? )
??? NS? dns1.mydomain.net.
??? NS? dns2.mydomain.net.
$ORIGIN uts-sa.mydomain.ddns.
$TTL 7200?? ; 2 hours
myhost? A?? 10.231.24.252
??? TXT 00e9e034c52bb28952e1b7192519421cc5
The SOA that it's serving is not the newest one.
--
Message: 3
Date: Mon, 06 Aug 2012 17:07:54 +0100
From: Phil Mayers p.may...@imperial.ac.uk
To: bind-users@lists.isc.org
Subject: Re: Delayed Zone Transfers?
Message-ID: 501febda.4040...@imperial.ac.uk
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 06/08/12 17:03, Jiann-Ming Su wrote:
Here's an example of the zone file being updated, but BIND not serving out
the new data.
Running dig locally:
# dig @localhost myhost.uts-sa.mydomain.ddns
I note from your other email that you are using views.
Are you sure you are querying the right view? It seems that you may be
querying the view in which the zone is not slaved, hence you get old,
cached data.
--
Message: 4
Date: Mon, 6 Aug 2012 19:12:56 +0300
From: Chris Buxton chris.p.bux...@gmail.com
To: Evan Hunt e...@isc.org
Cc: bind-users@lists.isc.org
Subject: Re: Multi-master DNS with Bind
Message-ID: f2f181ee-6156-4ae1-a10d-4bb7f7dc2...@gmail.com
Content-Type: text/plain; charset=us-ascii
On Aug 5, 2012, at 11:26 PM, Evan Hunt wrote:
Looking to find information as to whether I can set up bind for
multi-master DNS. I want to be able to update DNS records via any or more
than one nameserver in the domain and have the records updated and
propagated regardless if the master is available. Is this supported or
are there ways to make this work with bind?
Not at this time. We've discussed the subject at some length and it
may appear in a future release, but it's not on the near-term roadmap.
Couldn't this be done with DLZ?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
https://lists.isc.org/pipermail/bind-users/attachments/20120806/c725c5c7/attachment-0001.bin
--
Message: 5
Date: Mon, 6 Aug 2012 09:33:40 -0700 (PDT)
From: Jiann-Ming Su su_...@yahoo.com
To: bind-users@lists.isc.org bind-users@lists.isc.org
Subject: Re: Delayed Zone Transfers?
Message-ID:
1344270820.12060.yahoomail...@web39304.mail.mud.yahoo.com
Content-Type: text/plain; charset=iso-8859-1
From: Phil Mayers p.may...@imperial.ac.uk
To: bind-users@lists.isc.org
Cc:
Sent: Monday, August 6, 2012 12:07 PM
Subject: Re: Delayed Zone Transfers?
On 06/08/12 17:03, Jiann-Ming Su wrote:
Here's an example of the zone file being updated, but BIND not serving
out the new data.
Running dig locally:
# dig @localhost myhost.uts-sa.mydomain.ddns
I note from your other email that you are using views.
Are you sure you are querying the right view? It seems that you may be
querying
the view in which the zone is not slaved, hence you get old, cached data.
Yeah, I've wondered about views.? We went to views to work around a MTA config
issue.? The weird zone transfer performance seem to have coincided with our
transition to views.? Here's my named.conf, FWIW:
view hc {
??? match-clients? { 192.168.0.0/16; 10.236.0.0/16; };
??? match-destinations { any; };
??? include /etc/named.zones;
??? zone s7a1.psmtp.com {
??? type slave;
??? file db.postini-s7a1;
??? masters { dnsmgr; };
??? };
??? zone s7a2.psmtp.com {
??? type slave;
??? file db.postini-s7a2;
??? masters { dnsmgr; };
??? };
??? zone s7b1.psmtp.com {
??? type slave;
??? file db.postini-s7b1;
??? masters { dnsmgr; };
??? };
??? zone s7b2.psmtp.com {
??? type slave;
??? file db.postini-s7b2;
??? masters { dnsmgr; };
??? };
};
view all {
??? match-clients? { any; };
??? match-destinations { any; };
??? include /etc/named.zones;
};
For the particular case I demonstrated in the previous email, I don't think
views should have affected it as the default all view should have been hit.?
And even the hc view, the data would be the same as we're only spoofing for
the specific psmtp.com mail hosts.
--
Message: 6
Date: Mon, 6 Aug 2012 12:37:07 -0400
From: john.debe...@teradyne.com
To: Chris Buxton chris.p.bux...@gmail.com
Cc: bind-users@lists.isc.org
Subject: Re
Re: new bind 9.9 and root NS
-Original Message- From: Doug O'Leary dkole...@olearycomputers.com Date: Monday, August 6, 2012 9:58 AM To: 'Doug Barton' do...@dougbarton.us, Mike Hoskins micho...@cisco.com Cc: comp-protocols-dns-b...@isc.org comp-protocols-dns-b...@isc.org Subject: RE: new bind 9.9 and root NS After the network admin verified there was no firewall rule differences, we powered off the old secondary server and re-IPed the new one with the old secondary. The old secondary is able to get to the root nameservers w/o issue. Once we re-IPed the new one, it still was unable to get to the root nameservers via dig. Just checking the obvious; no host-based firewall on the new box? Is it the same OS? I also downloaded and installed lft - layer four traceroute (wonderful program, that one is). Lft was unable to get *anywhere* using udp regardless of what the IP address of the new system is. So, there's something with the virtualization software, vmware, which is preventing udp packets. There are some web sites saying the same thing so this isn't completely out of the blue. The client's opening a service call with vmware to see if there's a resolution. I'm serving several thousand clients using VMware + BIND, so I'm curious to see where this goes. :-) Which VMware product are you using, and what host platform? Thanks! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delayed Zone Transfers?
On 08/06/2012 05:33 PM, Jiann-Ming Su wrote:
Yeah, I've wondered about views. We went to views to work around a
MTA config issue. The weird zone transfer performance seem to have
coincided with our transition to views. Here's my named.conf, FWIW:
view hc { include /etc/named.zones;
view all { include /etc/named.zones;
You are includeing a set of zone defintions in two different views
here. Since your example zone doesn't appear to be in the main file, I
assume it's in the included file?
If so, this won't work, and will cause the problem you're seeing.
Basically you've got two views trying to write two different zones to
the same file and journal, but with distinct ideas of the in-memory
contents. Only one receives a notify and does IXFRs.
If you want a zone in two views, it must either be:
1. A simple type master with no DDNS allowed, or
2. Written to different files
In addition, NOTIFY is like any other DNS packet, and specifically it
goes into a view. This makes slaving a zone twice tricky - there is a
recipie in the FAQ using TSIG keys for this.
For the particular case I demonstrated in the previous email, I don't
think views should have affected it as the default all view should
Yes. But as per your *other* message, the notify (and therefore the
IXFR) happened in the hc view, so it's the one up-to-date:
06-Aug-2012 11:20:36.575 notify: client 192.168.8.8#33456: view hc:
received notify for zone 'uts-sa.mydomain.ddns': TSIG 'dns1.mydomain.org'
The all view will have to wait until the SOA refresh timer expires,
which explains your delay in the zone updating.
have been hit. And even the hc view, the data would be the same as
we're only spoofing for the specific psmtp.com mail hosts.
No. As above, this is not how views works with changing zone contents.
You can't write to the same file from two zones I'm afraid.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Multi-master DNS with Bind
On Aug 6, 2012, at 7:37 PM, john.debe...@teradyne.com wrote: Don't know. I haven't used it. Do you have experience with it? No, I don't have experience with DLZ. However, I believe multi-master DNS should be possible with DLZ and active-active database replication. Regards, Chris Buxton BlueCat Networks signature.asc Description: Message signed with OpenPGP using GPGMail ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delayed Zone Transfers?
From: Phil Mayers p.may...@imperial.ac.uk
To: bind-users@lists.isc.org
Cc:
Sent: Monday, August 6, 2012 2:37 PM
Subject: Re: Delayed Zone Transfers?
On 08/06/2012 05:33 PM, Jiann-Ming Su wrote:
Yeah, I've wondered about views. We went to views to work around a
MTA config issue. The weird zone transfer performance seem to have
coincided with our transition to views. Here's my named.conf, FWIW:
view hc { include /etc/named.zones;
view all { include /etc/named.zones;
You are includeing a set of zone defintions in two different views
here. Since your example zone doesn't appear to be in the main file, I
assume it's in the included file?
That is correct.
If so, this won't work, and will cause the problem you're seeing.
Basically you've got two views trying to write two different zones to
the same file and journal, but with distinct ideas of the in-memory contents.
Only one receives a notify and does IXFRs.
If you want a zone in two views, it must either be:
1. A simple type master with no DDNS allowed, or
2. Written to different files
In addition, NOTIFY is like any other DNS packet, and specifically it goes
into
a view. This makes slaving a zone twice tricky - there is a recipie
in the FAQ using TSIG keys for this.
For the particular case I demonstrated in the previous email, I don't
think views should have affected it as the default all view
should
Yes. But as per your *other* message, the notify (and therefore the IXFR)
happened in the hc view, so it's the one up-to-date:
06-Aug-2012 11:20:36.575 notify: client 192.168.8.8#33456: view hc: received
notify for zone 'uts-sa.mydomain.ddns': TSIG 'dns1.mydomain.org'
The all view will have to wait until the SOA refresh timer expires,
which explains your delay in the zone updating.
have been hit. And even the hc view, the data would be the
same as
we're only spoofing for the specific psmtp.com mail hosts.
No. As above, this is not how views works with changing zone contents. You
can't write to the same file from two zones I'm afraid.
Man, thanks so much for the insight! Given our DNS architecture, I think I can
do what I want without views.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Multi-master DNS with Bind
Not at this time. We've discussed the subject at some length and it may appear in a future release, but it's not on the near-term roadmap. Couldn't this be done with DLZ? DLZ is a mechanism by which it could be done, but as far as I'm aware no one has done it. You'd need a database that did active data replication on the backend, and a DLZ driver for that database which supported dynamic updates. (The DLZ API introduced in BIND 9.8 has support for those, but most existing DLZ drivers are still using the older API.) I wouldn't want to do it that way, though; DLZ's too slow. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
