-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
And now upgrade ;)
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4022
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0097
It will never end with BIND - MUUUuuaaaahahahahaha!
pls see below for additional comments.
On 6/4/2010 2:22 PM, Mike Hammett wrote:
> I got the errors to stop (period after the Origin, put there by a config
> generator), but it still doesn't answer for itself and looks to the
> roots and so on.
Don't do that Mike.
>
> If I'm issuing the command as I stated below, it shouldn't matter that
> the public authoritative server is elsewhere, would it?
Yes it absolutely does.
What you might do, depending on what you're trying to do, is create a
new NS RR for it in the master db file, and then slave the master.
You can also make your machine a manual master by doing an AXFR of the
zonefile from the AUTH server, then changing the SOA and NS Records in
that zonefile to indicate that your new server is actually the (or at
least one of) AUTH name server for that zone.
But really, most of the reasons you would do the second item (which it
sounds like you're trying to do), probably aren't part of why you're
doing this.
If you want the server to answer AUTH, then merely slave the master, coz
what you're doing is bordering on what is known as creating a 'hidden
master'. Which is what we do with servers for rootzones or TLD zones
where the real master isn't even accessible from the outside, and only
allows for zone AXFRs from the machines that are 'slaving' the hidden
master, and even though they're slaving it, it is their IPs that are in
the NS records as AUTH for the zone(s), making them AUTH, and masters,
even though they're slaving the zone from a hidden master.
We do this too in registries.
I'm trying to
> build this new system without messing with the production system.
Just edit the db file for the zone in question on the master, adding
your new box as AUTH for the zone w/an NS RR, then on the new box,
merely slave the master.
Don't forget to up your serial before HUP'ing the master when you load
the new zonefile.
if you are trying to set up a new forward facing master, and slave the
zone from a hidden master, then the SOA should be the machine that is
slaving the hidden master, and all other AUTH servers should simply
slave that machine's zonefile, with their glue included in that file.
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> On 6/4/2010 1:12 PM, Mike Hammett wrote:
>> I'm trying to setup a new authoritative BIND server, but all test
>> queries I issue to the server (dig @serversIP test.domain) get forwarded
>> to the root servers and so on. My zones have recursive searching
>> disabled. How is this happening?
>>
>> There are errors in loading the zone, but if all queries are being sent
>> out to the public Internet, how am I going to be able to test the new
>> system?
>>
>>
>
>
> --------------------------------------------------------------------------------
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> --------------------------------------------------------------------------------
>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>
- --
Bradley D. Thornton
Manager Network Services
NorthTech Computer
TEL: +1.760.666.2703 (US)
TEL: +44.702.405.1909 (UK)
http://NorthTech.US
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAwAGBQJMJR80AAoJEE1wgkIhr9j3bNsH/Arq5Vy7fQiSgKrQDqfQq0mM
+Qp4Psg20GgTVeBDsDytH13MSNUrPu+3JhaUbPc+b7hr+f7qxgbXfardhLQxpP2V
mI2A3NZB2TfMAMYKhdrYEJOedCrFa/Jmz6gjDuQvvDUQG3aCE0N10mXhkXBgsTUJ
F+FGLRAlvAhWB5TimXhV+vWfmwNjkz55jaWPv/lBN3VGosfoVmcAtvizV3yywixx
Ia+pYrgpGw98ao4/tbdwt4ZHF7syPJ98DHa3qCo5GEqD9ljujcyU8olpjptx5W/l
FYEfikQeTF/LgCdCESifeNrHrjQofrfqvtKxXOUpf/WkGVMDHchZOjDH7mrQ/+I=
=F0dn
-----END PGP SIGNATURE-----
--------------------------------------------------------------------------------
WISPA Wants You! Join today!
http://signup.wispa.org/
--------------------------------------------------------------------------------
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
