Hello specialists,
on my I have the Zones
[ '/etc/bind/named.conf.local' ]
key "rndc-key" {
algorithm hmac-md5;
secret "BSUwy6++2xFhBQpORuNkNQ==";
};
key "tdnet.key" {
algorithm hmac-md5;
secret
"ZHGU8pispV/4thVpZeBiRuvZtJ
I am structuring a named roll out which has a large amount of common data but
also has variable data in the IP addresses used to reach masters.
I want to include a standard file in the named.conf file which lists all of the
zones to be slave from a particular master set. Within this file I want
On Jan 19, 2010, at 5:12 AM, Howard Wilkinson wrote:
> I am structuring a named roll out which has a large amount of common data but
> also has variable data in the IP addresses used to reach masters.
>
> I want to include a standard file in the named.conf file which lists all of
> the zones to
Chris,
thanks for this. I had forgotten I could do this with modern bind
implementations. Just what I need.
Howard.
Coherent Technology Limited, 23 Northampton Square, Finsbury, London EC1V 0HL,
United Kingdom
Telephone: +44 20 3355 6467 Mobile: +44 7980 639379
Company Email: coher...@cohte
Luckily my machines have enough horsepower not to shut down from this
but I have on occasion seen the CPU load start going up due to it. On
lowered powered machines this would likely cause what you're seeing.
If you're running a firewall (external device or iptables on Linux) the
best way to dea
BIND 9.6.1-P3 is now available.
BIND 9.6.1-P3 is a SECURITY PATCH for BIND 9.6.1. It addresses two
potential cache poisoning vulnerabilities, both of which could allow
a validating recursive nameserver to cache data which had not been
authenticated or was invalid.
B
BIND 9.4.3-P5 is now available.
BIND 9.4.3-P5 is a SECURITY PATCH for BIND 9.4.3. It addresses two
potential cache poisoning vulnerabilities, both of which could allow
a validating recursive nameserver to cache data which had not been
authenticated or was invalid.
B
BIND 9.5.2-P2 is now available.
BIND 9.5.2-P2 is a SECURITY PATCH for BIND 9.5.2. It addresses two
potential cache poisoning vulnerabilities, both of which could allow
a validating recursive nameserver to cache data which had not been
authenticated or was invalid.
B
OK I had a loging error and now gotten this at a restart:
[ '/var/log/named.log' ]
Jan 19 18:56:40 samba3 named[25369]: 19-Jan-2010 18:56:40.613 general: info:
shutting down: flushing changes
Jan 19 18:56:40 samba3 named[25369]: 19-Jan-2010 18:56:40
Michelle Konzack wrote:
> Jan 19 18:56:42 samba3 named[18333]: 19-Jan-2010 18:56:42.920 general: error:
> dns_master_load: /etc/bind/net.tamay-dogan.debian:18:
> lists.debian.tamay-dogan.net: CNAME and other data
> This give an error?
Yes. Look at line 18. lists is duplicate.
>> [ '/et
On Tue, 19 Jan 2010, Michelle Konzack wrote:
> Jan 19 18:56:42 samba3 named[18333]: 19-Jan-2010 18:56:42.920 general:
> error: dns_master_load: /etc/bind/net.tamay-dogan.debian:18:
> lists.debian.tamay-dogan.net: CNAME and other data
See line 18 and then look for "lists".
_
Correct. You can't have "lists" be a CNAME and also have it own an MX
record. The zone is invalid.
You can probably just whack the CNAME for "lists" and add one for the
target of the CNAME (vserver3.tamay-dogan.net), which will function the
way you apparently intended. Be aware, however, that
All,
Last Friday (Jan 8th 2010) Matt Larson from Verisign started a thread on
the NANOG mailing list titled "Upcoming DNS behavior changes to
.com/.net/.edu name servers". I haven't seen any chatter on here or NANOG
in regards to the post and figured now would be as good a time as any to
start
Sorry, I meant "whack the MX for 'lists'"...
- Kevin
--- Begin Message ---
Correct. You can't have "lists" be a CNAME and also have it own an MX
record. The zone is invalid.
You can probably just whack the CNAME for "lists" and add one for the
target of the CNAME (vserver3.tamay-dogan.net),
On 01/19/10 11:36, da...@from525.com wrote:
All,
Last Friday (Jan 8th 2010) Matt Larson from Verisign started a thread on
the NANOG mailing list titled "Upcoming DNS behavior changes to
.com/.net/.edu name servers". I haven't seen any chatter on here or
NANOG in regards to the post and figured n
> Date: Tue, 19 Jan 2010 13:36:39 -0600
> From: "da...@from525.com"
>
> All,
>
> Last Friday (Jan 8th 2010) Matt Larson from Verisign started a thread
> on the NANOG mailing list titled "Upcoming DNS behavior changes to
> .com/.net/.edu name servers". [...snip...]
>
> http://mailman.nanog.org/p
Helle Kevin,
Am 2010-01-19 14:29:59, schrieb Kevin Darcy:
> Correct. You can't have "lists" be a CNAME and also have it own an
> MX record. The zone is invalid.
OK
> You can probably just whack the CNAME for "lists" and add one for
> the target of the CNAME (vserver3.tamay-dogan.net), which will
It is against the DNS rules to have a CNAME and any other record type exist
at the same level of the DNS tree.
For instance you can have a domain called foo.com and then try to do
foo.comIN CNAME
bar.com because the CNAME collides with the SOA and NS records for the
domain.
On Tue, Jan 19, 2010 at
These announcements for BIND 9.4.3-P5, 9.5.1-P2 and 9.6.1-P3 say
BIND 9.x.x-Px is a SECURITY PATCH for BIND 9.x.x. It addresses two
potential cache poisoning vulnerabilities, both of which could allow
a validating recursive nameserver to cache data which had not been
authenticated or was invali
Sorry, I mistyped my first message. I meant you could remove the MX
records owned by "lists", and make them owned by
vserver3.tamay-dogan.net instead.
That would direct "lists" mail to exactly the same place(s), while
leaving "lists" only owning a single CNAME record. The zone would be
legal
> But the CHANGES files list *three* security fixes (2827, 2828 & 2831),
> none of which seem to be superficially the "same" vulnerability. So is
> the "two" above a mistake?
There are two vulnerabilities (see the CERT advisories). One of them, we
thought we'd fixed it, then we noticed something
Hi, I've run into some strange issues with BIND and CNAMES. We're using BIND9
(on Ubuntu) internally and have our external DNS hosted by NetworkSolutions.
Occasionally I'll be able to create a CNAME in NetworkSolutions that BIND is
unable to resolve.
Using dig I notice it's doing a query for an
Hi
we are running BIND 9.2.1 on AIX 5.3 TL11. Now, I would like to upgrade it
to BIND 9.6.1-p3.
Is this BIND version is stable?
Can anybody help me to suggest how upgrade the BIND with minimal impact? I
am running BIND in "bind-jail".
Thanks for your help.
Regards
Nagaraj
_
23 matches
Mail list logo
