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 ca
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 o
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 consider
Apologies in advance for the longer than intended reply.
I've spent a lot of time reviewing documents regarding timing values and
they vary quite widely. One observation I've made is that many
recommendations, especially those that are a little older, are predicated on
the assumption that the proc
On 20/09/10 6:09 PM, "Kevin Oberman" wrote:
>> Date: Mon, 20 Sep 2010 11:03:31 +0200
>> From: Kalman Feher
>> Sender: bind-users-bounces+oberman=es@lists.isc.org
>>
>> Apologies in advance for the longer than intended reply.
>>
>> I&
On 21/09/10 8:43 AM, "Niobos" 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 (DNS) Guide
On 21/09/10 3:43 PM, "Niobos" wrote:
> On 2010-09-21 15:32, Kalman Feher wrote:
>> On 21/09/10 8:43 AM, "Niobos" wrote:
>> I personally find protection against zone enumeration to be a false sense of
>> security. If it's public people will find
On 22/09/10 4:14 AM, "Doug Barton" 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 s
On 22/09/10 11:29 AM, "Matus UHLAR - fantomas" 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
>>> yo
On 29/09/10 10:30 PM, "Kevin Oberman" wrote:
>> Date: Wed, 29 Sep 2010 15:51:55 -0400
>> From: "Taylor, Gord"
>> Sender: bind-users-bounces+oberman=es@lists.isc.org
>>
>>
>> We recently ran into an intermittent problem sending queries to a
>> business partner. Turns out they had CheckPo
On 1/10/10 9:15 AM, "Joerg Dorchain" 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 zone ty
On 2/10/10 7:18 AM, "Joerg Dorchain" wrote:
> On Fri, Oct 01, 2010 at 05:39:16PM +0200, Matus UHLAR - fantomas wrote:
>>
>> On 01.10.10 12:39, Joerg Dorchain wrote:
>>> Well, I could agree agree that "wrong" means not thought of by
>>> RfC-Designers and bind implementators (yet).
>>
>> proba
On 11/10/10 1:02 PM, "Alans" 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 and 9.7.1-P2
On 13/10/10 12:13 PM, "Andrey G. Sergeev" 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 alw
On 26/11/10 5:58 AM, "Mark Andrews" wrote:
>
> In message ,
> 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 investigation with the network guys, it appear that our upstream
>>
On 20/12/10 11:05 AM, "Laurent Bauer" wrote:
>
> Hello,
>
> We (my company) are registrar for a domain name which is delegated to
> our client NS. Our client wanted to change the NS records (just the
> names, same IP addresses) but the registry put the wrong names and
> created glue records
On 20/12/10 4:18 PM, "Laurent Bauer" wrote:
> On 20/12/2010 13:50, Kalman Feher wrote:
>>> The registry NS return an authority section like :
>>>> domain.tld. IN NS ns1.domain.tld.
>>>> domain.tld. IN NS ns2.domain.tld.
>>
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
I'm curious whether the domain in question had a DS in the parent zone?
On 11/01/11 4:52 PM, "Chris Thompson" wrote:
> On Jan 11 2011, Alexander Gall wrote:
>
>> It appears that NODATA responses for qtype=DNSKEY are not cached if
>> DNSSEC validation is enabled (tested with 9.7.2-P3). What is
On 14/01/11 9:57 AM, "Peter Andreev" wrote:
> 2011/1/13 Alan Clegg :
>> On 1/13/2011 11:08 AM, Peter Andreev wrote:
>>
>>> I've executed
>>> rndc addzone test.test '{ type master; file "/etc/namedb/master/test.1"; };'
>>>
>>> and have got the file /etc/namedb/3bf305731dd26307.nzf:
>>> zone t
On 14/01/11 12:51 PM, "Peter Andreev" wrote:
> 2011/1/14 Kalman Feher :
>>
>>
>>
>> On 14/01/11 9:57 AM, "Peter Andreev" wrote:
>>
>>> 2011/1/13 Alan Clegg :
>>>> On 1/13/2011 11:08 AM, Peter Andreev wrote:
>>
On 14/01/11 1:26 PM, "Tom Schmitt" wrote:
> I just read the release notes from Bind 9.7.2-P3 and noticed that behind every
> short description of a change there is a number beginning with RT.
> I hope this is some kind of ticket number were more detailed information about
> this change could be
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 as values. When initially
testing I used lifetim
>
> W 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
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.
-options
On 21/01/11 2:05 PM, "Zbigniew Jasiński" 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
On 24/01/11 10:53 AM, "Zbigniew Jasiński" 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?
On 24/01/11 4:08 PM, "Zbigniew Jasiński" 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 NS
On 25/01/11 2:34 PM, "Zbigniew Jasiński" 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 coul
On 25/01/11 4:10 PM, "Alan Clegg" 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 worki
On 25/01/11 11:20 PM, "Mark Andrews" wrote:
>
> In message , Kalman Feher
> write
> s:
>>
>>
>>
>> On 25/01/11 4:10 PM, "Alan Clegg" wrote:
>>
>>> On 1/25/2011 9:51 AM, Kalman Feher wrote:
>>>
>>>
On 4/02/11 3:07 AM, "Tory M Blue" wrote:
> On Thu, Feb 3, 2011 at 5:23 PM, Barry Margolin wrote:
>> In article > SNIPPED<
>> www.yahoo.com. 300 IN CNAME fp.wg1.b.yahoo.com.
>>
>> And even when they did, it didn't get involved until you followed the
>> CNAME returned for www.yahoo.com.
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" 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
>
> Some
On 1/05/10 7:10 PM, "Server Administrator" 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 close enough
On 3/05/10 7:34 PM, "Lightner, Jeff" 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
5/5 will not req
On 3/05/10 9:54 PM, "Lightner, Jeff" 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 problem.
This appe
On 3/05/10 10:25 PM, "Ray Van Dolson" wrote:
> David, I think you're exactly right. Lots of FUD, but, if I understand
> correctly, BIND does by default does send out EDNS0 signalling by
> default...
EDNS0 does not imply DNSSEC. So you can get large responses back for lots of
non DNSSEC querie
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" 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 nsu
I was obviously especially tired yesterday when I tested this.
Anyway BIND was chroot'd and user wasn't.
(slaps forehead)
Problem solved.
On 30/06/10 6:07 PM, "Kal Feher" wrote:
>
>
>
> On 30/06/10 5:25 PM, "Alan Clegg" wrote:
>
>> O
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 or
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 netsta
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: versio
13/07/10 3:10 PM, "Gilles Massen" 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 tidie
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
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 and
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"
wrote:
On Fri, Jul 16, 2010 at 01:57:05PM +,
ALAIN AINA wrote
a message of 20 lines which said:
https://itar.iana.org/i
On 27/07/10 8:10 AM, "Arnoud Tijssen" 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 not an opt
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" wrote:
> Fi
50 matches
Mail list logo
