You "copied over the zone files". However, the bind 9 server is
responding with NXDOMAIN. It appears to me that the server does not
believe it is authoritative for the zone. Verify that the server indeed
believes it is (look at the logs on startup). Take a look at your named
configuration t
I've noticed the support in ARM for specifying both the "forward" and
"forwarders" configuration in a zone stanza for "slave" zones. What is
the purpose and value of specifying such? It seems contradictory and
confusing.
-- John
___
Please visit ht
If that's an exact copy of your record, I'm going to also assume that
the ORIGIN at the time of the record is "toto.be". As such, the
resulting record becomes:
www.toto.be.toto.be. 86400 IN CNAME www.titi.be.toto.be.
Note that trailing '.'s are required to prevent the automatic addition
of t
s6 is a subdomain of the parent domain. Unless otherwise specified,
subdomains are mastered (NS'd) by the parent (or extended parent domain)
containing NS records. As such, because you didn't put any NS records
in the zone file for s6, it follows the NS records of the parent which
happen to b
The concept of a "secondary" master is sound. It basically provides for
a healthy means of handling the situation where your primary master is
unusable. To enable and support a primary/backup dns master, the backup
master is initially setup as noted as a slave server. Any other slave
serve
Assuming your architecture is:
2 DNS servers which answers to external queries (public facing)
1 DNS server which only answers to internal queries (internal facing)
All internal clients configured to query the internal facing DNS server
for resolution.
Then, simply place your domain in both the e
The OP stated he has 3 separate DNS servers. Two serving public and
one serving private. Under those circumstances, there is no specific
need or requirement for views. Views are only needed if the same DNS
server is answering to clients that you want to give out different
answers. If as the OP
The problem pointed out in your 'match-clients' is the first glaring
problem.
What you need to understand is that from the point of BIND, your slave
server is treated the same (from the view ) as any "client" for the
master and vice versa.
So, the communication between master and slave needs to b
NS records must point to an A record. ns1 and ns2 .nsdomain.com do
not have A records defined for them according to the zone file.
-- John
On 10/1/2010 12:14 AM, rams wrote:
Hi,
I have configured records as follows in bind. When we start the bind
9.7, bind is not starting.
But bind is star
Simply set the "file" option to the same name on the slave server.
On 10/2/2010 2:59 PM, Doug Barton wrote:
On 10/2/2010 11:16 AM, online-reg wrote:
Hi All: I’m building a new Bind 9.7.1-P2 slave server and am taking an
opportunity to review my conf files.
I have a number of zones on the prim
Doesn't support it? Since when does named not allow you to use the
same file name for more then one zone? I've been doing that for several
years.
-- John Wingenbach
On 10/2/2010 6:49 PM, Mark Andrews wrote:
In message<58f2f2eb90f24743a050575c87c7c...@nyoffice.enigmedia.lo
I know that per Mark Andrews that named does not support having
multiple zones pointing to the same zone file. I can understand the
issue if named does not support it for a slave server. What about for a
master server? Are there any issues with named supporting that?
I would assume that wh
https://www.isc.org/files/arm96.html#types_of_resource_records_and_when_to_use_them
Scroll down to the data type MX and it says:
Identifies a mail exchange for the domain with a 16-bit preference value
(lower is better) followed by the host name of the mail exchange.
Described in RFC 974, RFC
Don't confuse dig +trace with what is happening or not at your name
server. When trace is enabled, dig performs the queries needed itself
from the location the dig is run. So, in other words, if your system is
not allowed to send or receive DNS packets, then you'll never be able to
perform a
I run a multi-master environment. We have 3 data centers which are
considered to be able to run even though the rest are down. Initially,
we ran our masters with the same exact configurations on each. One of
the data centers was administratively defined as being the 'update
master'. From th
I wouldn't say we migrated in that direction due to anything other then
lack of good options. What BIND is missing is the concept of an update
master.
Augment BIND with the following:
* Each master is aware of the other masters.
* One master is defined as an update master (rndc control?)
*
What you are looking for is basically dnsmasq. That allows you to
override specific resolutions, while letting the rest go through the
normal process. BIND does not allow you to have split authority for a
single zone.
if you say something.xyz.com is handled locally, then anything under
that
17 matches
Mail list logo
