On 4/02/11 3:07 AM, Tory M Blue tmb...@gmail.com wrote:
On Thu, Feb 3, 2011 at 5:23 PM, Barry Margolin bar...@alum.mit.edu wrote:
In article mailman.1636.1296781581.555.bind-
SNIPPED
www.yahoo.com. 300 IN CNAME fp.wg1.b.yahoo.com.
And even when they did, it didn't get involved
On 25/01/11 11:20 PM, Mark Andrews ma...@isc.org wrote:
In message c964b3cd.13a61%kalman.fe...@melbourneit.com.au, Kalman Feher
write
s:
On 25/01/11 4:10 PM, Alan Clegg acl...@isc.org wrote:
On 1/25/2011 9:51 AM, Kalman Feher wrote:
If the nsec3param has been removed
On 25/01/11 2:34 PM, Zbigniew Jasiński szo...@nask.pl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
W dniu 2011-01-24 17:47, Kalman Feher pisze:
This appears to be the problem.
I copied your NSEC3PARAM (opt out clear, 12 iterations) details but could
not replicate it. Try
On 25/01/11 4:10 PM, Alan Clegg acl...@isc.org wrote:
On 1/25/2011 9:51 AM, Kalman Feher wrote:
If the nsec3param has been removed, the automated signing will be weird if
you are using nsec3 keys. I havent tested this scenario, since it isnt
really a working scenario
On 24/01/11 10:53 AM, Zbigniew Jasiński szo...@nask.pl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
W dniu 2011-01-21 15:17, Kalman Feher pisze:
Perhaps we are getting close to the problem then.
Can you show the content of the key files? Specifically the metadata which
On 24/01/11 4:08 PM, Zbigniew Jasiński szo...@nask.pl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
W dniu 2011-01-24 14:34, Kalman Feher pisze:
I assume you did add the nsec3param record via nsupdate after adding the
zone? I note that there is an NSEC entry there, which
The only way I can replicate the behaviour is with dnssec-enable no or with
an unsigned version of the zone in another view. Assuming you've not
overlapped your views in such a way (it was a very contrived test), I think
you'll need to provide a bit more information on your configuration.
On 21/01/11 2:05 PM, Zbigniew Jasiński szo...@nask.pl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
W dniu 2011-01-21 11:23, Kalman Feher pisze:
The only way I can replicate the behaviour is with dnssec-enable no or with
an unsigned version of the zone in another view. Assuming
dniu 2011-01-17 15:39, Kalman Feher pisze:
Have you tried more sane times?
Those don't look like sensible times even for a test, which is probably why
BIND isn't signing. I think you are below the sensitivity level for BIND to
sign automatically.
If you want to test, try using hours or days
What was the observed behaviour in your test system?
From a sanity point of view and if you are checking the zone prior to
accepting the DNSKEY, then I see nothing wrong in rejecting it. There are
already other restrictions on domains in .EU that establish a precedent for
being more demanding on
On 26/11/10 5:58 AM, Mark Andrews ma...@isc.org wrote:
In message aanlktimzmc4pgne7n72hnb7gnjuat9r2oktigaazv...@mail.gmail.com,
Rian
to Wahyudi writes:
Hi Mark,
Thanks for the pointers , your are spot on!
Doing dig +trace +dnssec www.paypal.com always fail.
After some
On 13/10/10 12:13 PM, Andrey G. Sergeev and...@aernet.ru wrote:
Hello Alans,
Tue, 12 Oct 2010 16:52:15 +0300 Alans wrote:
On 10/12/2010 03:44 PM, Andrey G. Sergeev (AKA Andris) wrote:
Hello Ian,
Tue, 12 Oct 2010 10:54:19 +0100 Ian Tait wrote:
Ok, but you can always browse by
On 11/10/10 1:02 PM, Alans alans...@gmail.com wrote:
Hello,
Is it possible for bind dns to check the queries, if the returned answer
is existed in a file that contains blacklisted IPs then block it?
DNS RPZ may do what you want.
There is a patch on the isc.org website for 9.4,9.6
On 1/10/10 9:15 AM, Joerg Dorchain jo...@dorchain.net wrote:
On Thu, Sep 30, 2010 at 07:13:11PM -0400, Kevin Darcy wrote:
Per-zone recursion control doesn't exist in BIND, because frankly it
doesn't make sense.
I used to think that, too, until I came to my specific problem.
Either a
On 29/09/10 10:30 PM, Kevin Oberman ober...@es.net wrote:
Date: Wed, 29 Sep 2010 15:51:55 -0400
From: Taylor, Gord gord.tay...@rbc.com
Sender: bind-users-bounces+oberman=es@lists.isc.org
We recently ran into an intermittent problem sending queries to a
business partner. Turns out
On 22/09/10 4:14 AM, Doug Barton do...@dougbarton.us wrote:
On 9/21/2010 7:46 AM, Kalman Feher wrote:
It may well be analogous to that (though I disagree), but the quote does not
substantiate why knowing public information is bad. In the example above,
you've simply saved your switchboard
On 22/09/10 11:29 AM, Matus UHLAR - fantomas uh...@fantomas.sk wrote:
I'll reply with a quote from the BIND DNS book:
It¹s the difference
between letting random folks call your company¹s
switchboard and ask
for John Q. Cubicle¹s phone number [versus] sending
them a copy of
your
On 21/09/10 8:43 AM, Niobos nio...@dest-unreach.be wrote:
Thank you for the excellent advice!
On 2010-09-20 18:09, Kevin Oberman wrote:
I recommend anyone attempting to secure their DNS read the NIST Computer
Security Resource Center document SP800-81 Rev.1, Secure Domain Naming
System
On 20/09/10 6:09 PM, Kevin Oberman ober...@es.net wrote:
Date: Mon, 20 Sep 2010 11:03:31 +0200
From: Kalman Feher kalman.fe...@melbourneit.com.au
Sender: bind-users-bounces+oberman=es@lists.isc.org
Apologies in advance for the longer than intended reply.
I've spent a lot of time
For the TCP issues check your network.
I'm not familiar with DLZ, but it may be worth understanding how it is
effected by the addition-from-[auth|cache] options. Since you get the full
response once, I presume you do not have minimal responses enabled.
My ignorance of DLZ is showing, but
So the cache servers are HA behind something (F5 LTM, Cisco local director,
something else). Are the authoritative servers? It would seem sensible to do
the same with them. That way a timeout only occurs if the whole HA cluster
is unavailable.
You can alleviate even that situation by seeding the
Sign them offline or out of band using a database trigger to initiate the
signing. Your schema might need to change a little though.
For a ccTLD, your private key should probably be secure and offline anyway.
Zone updates should be reasonably automatable using either the BIND dnssec
tools or any
Perhaps you could explain the reasoning behind the request? If you are
trying to preserve resources there are better ways.
If you are trying to restrict access to master/slave zones then you should
use access lists, either at zone or view level.
On 11/08/10 3:42 PM, Dangl, Thomas
On 27/07/10 8:10 AM, Arnoud Tijssen atijs...@ram.nl wrote:
I`m facing kind of a challenge. At the moment we have BIND and windows DNS
within our corporate network.
I would like to get rid of windows DNS and switch completely over to BIND, but
since DNS is so intertwined with AD this is
My earlier post described altering the format and included the file
that anchors2keys would work with.
Kal Feher
On 17/07/2010, at 23:46, Stephane Bortzmeyer bortzme...@nic.fr
wrote:
On Fri, Jul 16, 2010 at 01:57:05PM +,
ALAIN AINA aal...@trstech.net wrote
a message of 20 lines
As a once off I did the following last night. (yes I know the DNSKEY would
have been fine too). anchors2keys worked fine so long as the format was
correct so...
I just cut and pasted the content of :
https://data.iana.org/root-anchors/root-anchors.xml
Zone to delegation, algorithm, digest type
Using bind 9.7.1. w/ IANA test bed and not DLV:
dig +dnssec rrsig www.iis.se
; DiG 9.7.1 +dnssec rrsig www.iis.se
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 49621
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT
Using the ORG trust anchor from the ITAR yields the following result on
9.7.1 (no P1 patch). No initial time out.
# dig +dnssec -t RRSIG www.forfunsec.org
; DiG 9.7.1 +dnssec -t RRSIG www.forfunsec.org
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0,
It looks like normal NSEC to me, unless you are referring to an isolated
copy of the domain not accessible to the public:
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 22416
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version:
On 13/07/10 3:10 PM, Gilles Massen gilles.mas...@restena.lu wrote:
Kalman Feher wrote:
It looks like normal NSEC to me, unless you are referring to an isolated
copy of the domain not accessible to the public:
Yes, indeed, sorry about that. I should keep my playgrounds tidier. The
actual zone
Since you now know that BIND doesn't send email and its possible to name a
virus whatever the virus writer wishes, it might be prudent to compare the
file with a known good version from here (check signatures):
ftp://ftp.isc.org/isc/bind9/
While off topic for this forum, you should also try
If you really do have such a small pipe (with your email address I assume
Sweden. I didn't think Swedes even knew there were link types other than
fibre ;) )then perhaps you're throttling it to the point where your NTP sync
drops off.
Options:
Perhaps try some traffic shaping on the link. IXFR
AM, Kalman Feher wrote:
While testing bind 9.7.1 features including automated signing and
update-policy local. I encountered some strange behaviour using nsupdate -l.
When using nsupdate -l I was not able to update the zone in question and the
following error was generated:
update-security
While testing bind 9.7.1 features including automated signing and
update-policy local. I encountered some strange behaviour using nsupdate -l.
When using nsupdate -l I was not able to update the zone in question and the
following error was generated:
update-security: error: client 127.0.0.1#9292:
On 30/06/10 5:25 PM, Alan Clegg acl...@isc.org wrote:
On 6/30/2010 11:13 AM, Kalman Feher wrote:
While testing bind 9.7.1 features including automated signing and
update-policy local. I encountered some strange behaviour using nsupdate -l.
When using nsupdate -l I was not able to update
On 1/05/10 7:10 PM, Server Administrator server53a...@gmail.com wrote:
I tried OARC's DNS Reply Size Test on two of my name servers, both on
the same network, behind the same firewall router.
Both came back and reported DNS reply size limit is at least 3843
(results below).
Is 3843
On 3/05/10 7:34 PM, Lightner, Jeff jlight...@water.com wrote:
There is no EDNS entry in my named.conf. Do I need one, given that
above worked?
You probably should. Your resolver is saying its capable of handling 4096,
but apparently your network path may not support that. The changes on the
On 3/05/10 9:54 PM, Lightner, Jeff jlight...@water.com wrote:
On doing that however, I now see the advertised value is 3839 but the
at least value is 3828 on one and 3827 on the other as shown below.
Based on that it appears one should NOT set the edns-udp-size as it
doesn't fix the
Can you provide the domain name and an example of the problem?
That will help in identifying the issue.
On 8/03/10 11:21 AM, bsd b...@todoo.biz wrote:
Hello,
I am running an important subzone of .museum zone (which implements both
DNSSec and IDN) and I have a strange behavior going on
39 matches
Mail list logo
