On 09/05/2010 19:31, Warren Kumari wrote:
> I am *so* not an IDN person (although I did follow the IDNA WG for a
> while), but I *believe* that the process is just to convert the native
> UTF8 representation (تامايدوجان.سى) to punycode
> (xn--mgbaajmr6mmaps.xn--ygb8b). There are a bunch of tools t
Hi,
we will shortly start using IPv6 reverse DNS, and having never used
it before I thought Id ask those with some experience if they have any
words of wisdom before I make any horrible mistakes ;) Ive already had
a good read of a good many sites on the subject but still would like
to c
Hello,
I am trying to configure a bind9 view to allow recursion just for certain
domains. (This is bind-9.2.4-16.EL4 under RHEL4).
In fact, it doesn't even have to be real recursion, just forwarding to an
upstream recursive nameserver. The point is that the clients are only
authorised to look up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/05/2010 12:44:32, a.sm...@ukgrid.net wrote:
> we will shortly start using IPv6 reverse DNS, and having never used it
> before I thought Id ask those with some experience if they have any
> words of wisdom before I make any horrible mistakes ;)
In article ,
Bruce Ray wrote:
> You have until the expiry counter expires for a given zone.
>
> We typically run our expiries at a week to allow for this type of failure.
Make them 10 days - that way you can break things on a Friday, have a
week off and then fix them again on the Monday morni
Hi, list.
Today I came in and both my name server stopped answering queries. I
restarted the servers a couple of times and they are now up. I have posted
the primary/slave look below. My question is did I just get rid by the
kaminsky vulnerability? if so how can I determined what host caused th
In article ,
Matthew Seaman wrote:
> This means that the smallest chunk of IP space you can delegate is 16
> addresses, ...
Nitpick: The smallest chunk of IPv6 space you can delegate is a single
address, as you can for IPv4. You could also do RFC 2317 style
delegations to delegate chunks of
I think I see what the issue is,
http://www.kb.cert.org/vuls/id/725188
I was asking about kaminsky because I wasn't sure if I had previously
upgraded to fix that fix, which seems like I had and the problem is
something different.
From: P.A [mailto:ra...@meganet.net]
Sent: Monday, May
On Mon, May 10, 2010 at 10:19:33AM -0400,
P.A wrote
a message of 314 lines which said:
> I think I see what the issue is,
No. Completely unrelated.
> http://www.kb.cert.org/vuls/id/725188
In that case, the error was:
Jul 29 09:10:57 lilith named[2428]: db.c:619: \
REQUIRE(type
On Mon, May 10, 2010 at 10:05:47AM -0400,
P.A wrote
a message of 242 lines which said:
> My question is did I just get rid by the kaminsky vulnerability?
Not at all. The Kaminsky attack poisons the server, it does not crash
it.
> Primary server: BIND 9.4.3b2
Why do you run a beta version (a
On 5/10/2010 10:19 AM, P.A wrote:
> Primary server: BIND 9.4.3b2
Continue your upgrade process to a version of BIND that is supported. :)
http://www.isc.org/software/bind/versions
AlanC
signature.asc
Description: OpenPGP digital signature
___
bind-
Stephane, do you think I can get away with running 9.4.3-P5 that doesn't
seem to have any known issues. Also what exploit do you think caused my
original issue?
As far as running an old version its been stable for a long time and to be
honest I forgot I was running that version.
-Original Me
We're doing some DNSSEC testing with sub-zones of our main zone, and I
had a little accident largely due to my own incompetence today where I
basically did this:
1. Existing zone "example.com"; create new zone "sub.example.com"
2. Run a SQL->DNS update; *.sub.example.com RRs are removed from
A) Why do you assume an exploit at all? Hopefully you understand that
the vast majority of software crashes in the world are triggered by
benign transactions.
B) From the www.isc.org website:
"BIND 9.4-ESV-R1 is now available. BIND 9.4-ESV-R1 is revision 1 of the
extended release version for
Kevin,
At 1st I assumed an exploit after looking at the version of bind I was
using, which was a beta, I noticed that there was some talk of the beta
version crashing and the solution was to go to P1. Looking back on it I did
an emergency upgrade to the beta because of the kaminsky problem. Since
Hello,
I have setup some rdns with bind, when i try to start I get this error:
/etc/zones/master/reverses/88.8.207.in-addr.arpa:257: ignoring
out-of-zone data (254.88.8.207.in-addr.arpa)
I get it for each host in the reverse zone file. ANy idea whay Im doing wrong?
Thanks,
Jason
___
Thanks guys, the issue was i just needed to put the last octect in the
zone file.
Thanks,
Jason
On Mon, May 10, 2010 at 12:20 PM, Chris Buxton wrote:
> Your zone definition in named.conf must have a different name than
> what you expect. Check it for typos.
>
> Chris Buxton
> BlueCat Networks
>
Your zone definition in named.conf must have a different name than
what you expect. Check it for typos.
Chris Buxton
BlueCat Networks
On 5/10/10, Jason Davis wrote:
> Hello,
> I have setup some rdns with bind, when i try to start I get this error:
>
> /etc/zones/master/reverses/88.8.207.in-addr
At Mon, 10 May 2010 10:05:47 -0400,
"P.A" wrote:
> Today I came in and both my name server stopped answering queries. I
> restarted the servers a couple of times and they are now up. I have posted
> the primary/slave look below. My question is did I just get rid by the
> kaminsky vulnerability? i
Recursion is enabled/allowed at the view level, not the zone level.
One strategy would be to set up a view that matches recursive queries
only. Set allow-query to none at the view, then set it any (or
whatever) in each zone of type forward or stub.
Or if you want to use your root zone idea, make
Thanks to Tatuya Jinmei.
2408. [bug] A duplicate TCP dispatch event could be sent, which
could then trigger an assertion failure in
resquery_response(). [RT #18275]
-Original Message-
From: Stephane Bortzmeyer [mailto:bortzme..
I have downloaded 9.7.0-P1 and I am running into something odd with
named-checkzone
I have a simple zone with an NS record that has no A or record.
named-checkzone has flags to ignore this. and this same command (see below)
worked in 9.6
but given this zone file
test.net. 500 IN SOA d88.te
Correction:
I am calling named-checkzone not checkconf.
this:
named-checkconf -k ignore -n ignore -i none test.net.
should read
named-checkzone -k ignore -n ignore -i none test.net.
the rest of the email is correct
From: Jack Tavares
Sent: Monday, May 10, 2010 12:49 PM
To: bind-users@lists.is
I see this was intentional.
2800. [func]Reject zones which have NS records which
refer to
CNAMEs, DNAMEs or don't have
address record (class IN
only). Reject UPDATEs which
wou
Hello Chris Hills,
Am 2010-05-10 09:02:35, hacktest Du folgendes herunter:
> I sent a requests to isc for a new option in dig, enabled by default:-
>
> +[no]idn
>automatically convert input to IDN
>
> So entering:-
>
> digتامايدوجان.سى
>
> would give you the result as if you had entered:-
In message <20100510124432.19374b1xzk3ab...@webmail2.ukgrid.net>, a.sm...@ukgri
d.net writes:
> Hi,
>
>we will shortly start using IPv6 reverse DNS, and having never used
> it before I thought Id ask those with some experience if they have any
> words of wisdom before I make any horrible
In message <4be82427.5060...@imperial.ac.uk>, Phil Mayers writes:
> We're doing some DNSSEC testing with sub-zones of our main zone, and I
> had a little accident largely due to my own incompetence today where I
> basically did this:
>
> 1. Existing zone "example.com"; create new zone "sub.exam
On May 10, 2010, at 6:48 PM, Michelle Konzack wrote:
Hello Chris Hills,
Am 2010-05-10 09:02:35, hacktest Du folgendes herunter:
I sent a requests to isc for a new option in dig, enabled by
default:-
+[no]idn
automatically convert input to IDN
So entering:-
digتامايدوجان.سى
would give
In article ,
Jason Davis wrote:
> Thanks guys, the issue was i just needed to put the last octect in the
> zone file.
That doesn't sound right. As long as the suffix matched the zone name,
it shouldn't have caused the error you got.
254 IN PTR
is equivalent to
254.88.8.207.in-addr.arpa. IN
Hi,
I have delegation of NS records in my zone and i signed zone using RSASHA1
algorithm. It is signed successfully. When I checked the the zone i am not
seeing RRSIG for delegated NS records. When I query for delegated NS record
with dnssec, it is returning NS records, NSEC and RRSIG for NSEC and
In message , rams
writes:
> Hi,
>
> I have delegation of NS records in my zone and i signed zone using RSASHA1
> algorithm. It is signed successfully. When I checked the the zone i am not
> seeing RRSIG for delegated NS records.
There arn't supposed to be any. The child zone is authoritative
f
31 matches
Mail list logo
