In article ,
Stewart Dean wrote:
> I did exactly that, but that wasn't what I was asking (I don't think).
>
> What I want to know is about how the nameserver host itself handles any calls
> it itself makes to localhost. If I have one view handling 10. addresses and
> the other handling ALL
I did exactly that, but that wasn't what I was asking (I don't think).
What I want to know is about how the nameserver host itself handles any calls
it itself makes to localhost. If I have one view handling 10. addresses and
the other handling ALL others (match-clients { any; }, then it would
My question is how can you detect if a DSN / Domain name
has been 'poisoned'?
--
Member - Liberal International This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca
God, Queen and country! Never Satan President Republic! Beware AntiChrist
rising!
http://twitter.com/rootnl2k http://www.facebook.com/
There was a report on NANOG about this earlier. We are getting
responses, but they were a bit slow to resolve.
Michael Hare wrote:
> Hello-
>
> Our recursive nameservers are having trouble with .MIL today. I see
> some public servers [8.8.8.8] are not. I am not running a dns-sec
> enabled recur
Hello-
Our recursive nameservers are having trouble with .MIL today. I see
some public servers [8.8.8.8] are not. I am not running a dns-sec
enabled recursive resolver.
In the below I was expecting an 'ADDITIONAL' section, not based on the
DIG header, but based on expecting delegation glue
What I have done is add another IP to boxes with views, one per view (ie:
127.0.1.1/2/3/4). Then put one of those ips in each view match statement.
When you do your dig, you tell it to source from a specific interface (dig -b
127.0.1.1 @localhost record.ext). That will ensure that you can hit
I have set up a nameserver as per pg 249 of DNS & Bind, 5th Ed. The host is on
two networks, serving the internal 10 based network as nsi at 10.5.0.5 with an
internal view and the external network as nsx at 192.246.229.x with an external
view. Everything makes sense until I get to the match-cl
On Mon, 25 Oct 2010, Adam Tkac wrote:
I have seen the “Actualización de ISC BIND 9.7” for the vulnerability with
DNSSEC
Is possible to install the last bind version 9.7 p2 directly in my REDHAT?
Yes, it is. You can download it from ISC site and compile it.
Or use rpm to rebuild the rhel6bet
On Mon, Oct 25, 2010 at 11:54:02AM +0200, Javier Civera wrote:
> Hello colleagues,
Hello,
> I have a REDHAT 5.4 (gcc 4.1.2) ,
>
>
>
> named -v
>
> BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.1
The latest released version of BIND for RHEL 5 is
# rpm -q bind
bind-9.3.6-4.P1.el5_4.2
# /usr/sbin/name
Hello colleagues,
I have a REDHAT 5.4 (gcc 4.1.2) ,
named -v
BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.1
I have seen the “Actualización de ISC BIND 9.7” for the vulnerability with
DNSSEC
My question ,
Is possible to install the last bind version 9.7 p2 directly in my REDHAT?
Or for RedH
10 matches
Mail list logo