key-directory "/etc/bind/keys";
sig-validity-interval 3;
};
And to be completely honest: the configured slave NS record doesn't
really slave this zone; but BIND shouldn't know or care.
greets,
Niobos
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
On 2010-09-17 12:15, Tony Finch wrote:
> On 17 Sep 2010, at 10:44, Niobos <mailto:nio...@dest-unreach.be>> wrote:
>>
>> In my opinion, BIND should have resigned this by now: The signature is
>> valid until a little over 2 days. This means that if the slave would
&g
On 2010-09-17 19:50, Tony Finch wrote:
> On 17 Sep 2010, at 14:10, Niobos <mailto:nio...@dest-unreach.be>> wrote:
>>
>> Is the current version of the ARM available online somewhere?
>
> http://dotat.at/tmp/arm97/
>
> IIRC the specific version that comes fr
).
My signature lifetime will probably be 3 weeks, resigning every week.
With 1 week expire timers, it leaves 1 week of margin to correct errors.
Are these values/argo's sane?
Thx,
Niobos
PS: don't try talking me into using NSEC. I'm using NSEC3 &quo
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" at:
> http://csrc.nist.gov/publications/nistpubs/
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 it. Ask your self what it is that
> you want publically accessibl
; prevent that is likely to waste more of your time than it will of those
> looking.
Unless you're calculating the NSEC3 hashes by hand, it took me under 1
minute to add an NSEC3PARAM RRset to my zone. And I'm fairly confident
that it will take at least 1 minute longer to walk an NSEC3 zon
On 2010-09-21 16:56, Phil Mayers wrote:
> On 21/09/10 14:43, 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
&g
turn a SOA, so they seem to know about it
* if these servers have correct zone data? none of them returns NS records
Greets,
Niobos
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
oo can see when a zone
was last edited, even down to the second, by watching the RRSIG(SOA) timing.
just my 2 cents,
Niobos
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
On 2010-10-15 17:14, João Alberto Kuchnier wrote:
> Dispite of that, I'm having some problems with reverse DNS. MxToolBox,
> for example, is saying that my reverse DNS is not configured.
That's because it isn't:
if I query for 3.101.198.200.in-addr.arpa (i.e. the reverse lookup for
IP 200.198.101.
On 2010-10-15 20:23, Jukka Pakkanen wrote:
> 15.10.2010 20:54, Niobos kirjoitti:
>> What's the advantage of using a date anyway? I too can see when a zone
>> was last edited, even down to the second, by watching the RRSIG(SOA)
>> timing.
>
> Time usually goes to o
On 2010-10-26 00:39, The Doctor wrote:
> My question is how can you detect if a DSN / Domain name
> has been 'poisoned'?
By using DNSSEC
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
allow for reasonable interaction between the
>various timer and expiry dates.
If your TTL is longer than 7.5 days, bind will NOT resign correctly
without this option.
greetings,
Niobos
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
ailure mode (3), which will cause a
noticeable delay.
Niobos
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
I match clients based on the
(destination/server) port they used to contact BIND?
Is this possible? Or is there a much easier way to solve my problem and
am I overly complicating things?
And you never know: if anyone has ever installed BIND 9.7 on a dd-wrt
box, that would solve my problem
On 2011-03-01 21:00, Torinthiel wrote:
> On 03/01/11 20:17, fakessh @ wrote:
> And about OVH - I don't know if it's related, but I've asked Polish OVH
> how about providing DNSSEC, as .pl is planned to be signed mid-year, and
> they've answered me they will probably be ready. This might, or might
>
Have multiple views, one with MX records, one without
No, that would return NODATA. The original poster was looking for a
"deny", which I interpret as REFUSED.
Niobos
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.
o in the end, I decided to leave my KSK online and have BIND
automatically perform ZSK rollovers for me (KSKs are needed for this,
although you could pre-calculate all needed RRSIGs during all stages of
the rollover if you really want to)
Greets,
Niobos
___
; if anyone knows how to convince Mail.app to de this decently,
let me know)
dnssec.log
Description: Binary data
According to my understanding, this is a bug, probably in the caching. Can
anyone confirm this is actually a bug? Point me to the right config-parameter?
Or explain to me why this _isn
On 08 Dec 2009, at 15:18, Hauke Lampe wrote:
> Niobos wrote:
>
>> When requesting a lookup of "removed", I get a SERVFAIL as well. However,
>> every subsequent request for "removed" gets an NXDOMAIN. (dig outputs below)
>> Flushing the caches on the R
>> Could you try this lookup?
>> dig +dnssec removed.dnssec.dest-unreach.be
>
> I see now what you mean.
>
> Even though I have added your DNSKEY as trusted key, I get SERVFAIL on
> the first query and NXDOMAIN on the second, without BIND doing any
> additional outgoing queries.
This is the same
Thank you very much for your help; I'll forward the conversation to the
bug-tracking list.
Since these are my first DNSSEC experiments, I just wanted to make sure that it
wasn't a problem with my understanding of the concept.
Niobos
On 10 Dec 2009, at 00:59, Hauke Lampe wr
On 17 Dec 2009, at 20:50, Kevin Darcy wrote:
> Cat'ing the zone file is no longer reliable once you've enabled a zone for
> Dynamic Update. There might be updates in the log file which haven't been
> committed to the actual zone file yet. That's why I recommended that you use
> an AXFR of the zo
e the blackhole-statements from the config; instead add these
rules to iptables, ipfw or equivalent:
* Allow "related or established" packets to the DNS port
* Drop incomming DNS-requests from the blackhole nets
This will basically allow replies, but drop requests.
Greets,
Niobos
___
g delegation in .org shouldn't their Dig attempt to
connect to
ns1.v6ns.org instead (yes, they are the same machine but noone else
knows
this but me... and you!)?
I'm not a DNS expert, but I think it should. However, currently there
IS a A-glue for ns2
Niobos
_
On 12 Jan 2010, at 17:15, Lightner, Jeff wrote:
For BIND blocking
the version keeps the auditors from asking the question since they
don't
know base version let alone extended version.
Which tells more about the auditors than about the feature to do so
__
On 2009-12-10 08:49, Niobos wrote:
Thank you very much for your help; I'll forward the conversation to the
bug-tracking list.
Since these are my first DNSSEC experiments, I just wanted to make sure that it
wasn't a problem with my understanding of the concept.
Niobos
Thi
On 2010-02-16 13:32, Eugene Crosser wrote:
> Do you think there is an appropriate place somewhere for a small
> one-page HOWTO? I could document what I did and submit the result...
>
I for one would be interested!
Niobos
___
bind-users mai
se two tasks doesn't influence
> each other.
As far as I can tell, they DO: your modified answers will be marked as
BOGUS by DNSSEC and will be thrown away.
Niobos
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
t security statuses (bogus, insecure, secure).
Niobos
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
av
In this configuration, the server's IP is present multiple times, which
will lead to mistakes in the future. I can't let the SRV-record point
directly to "server" either, since the vhost-configuration needs the
correct Host:-HTT
st for net./NS)
only yield an RRSIG over the NSEC RRset, not over the NS RRset and not
over the glue A-records (which are in bailiwick, and I have "no other
way" to resolve them)
Can anyone clarify?
thx,
Niobos
$ dig @l.root-servers.net. +dnssec example.net. A
; <<>>
On 2010-07-16 12:36, Alan Clegg wrote:
> .net isn't signed, and you don't sign "out-of-zone" data (glue and
> delegation NS records).
But org. is signed, and gives the same result.
But anyway, it basically boils down to:
> On 7/16/2010 6:25 AM, Niobos wrote:
>
That makes it clear for me; thank you very much!
As an unrelated side-note: does anyone know when org.'s DS will be
included in the root zone?
Niobos
On 2010-07-16 14:08, Alan Clegg wrote:
>> Trying to enhance that: Am I correct to state that it's not possible to
>> va
On 2010-07-23 22:52, Peter Laws wrote:
> I would have expected that it would only ask the second-listed master if
> the first didn't answer ... but I didn't write the code (and haven't
> read it either!
And how would your slave ever pick up an update on "second-listed
master" that (for whatever re
ter for
128/25.217.142.62.in-addr.arpa.
The original request (200.217.142.62.in-addr.arpa.) is mapped via a
CNAME to a name inside your zone, but this mapping is done by the
ns3.sci.fi. nameserver; hence recursion is needed.
Niobos
___
bind-users mailin
On 2010-07-29 15:00, Jukka Pakkanen wrote:
> Anyway we also have 62.142.217.64/27 IP network (you know what I mean)
> which should be delegated to our servers, but that still doesn't work.
> But it's probably a delegation problem.
>From my point of view, 62.142.217.64 is served by ns3.sci.fi (and
www.isc.org/software/bind/new-features/9.7
http://www.isc.org/community/blog/201006/bind-972-and-and-automatic-dnssec-signing
Niobos
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
uot; { type forward; forwarders { PRIV; }; };
>zone "HOST2" { type forward; forwarders { PRIV; }; };
># PUB and PRIV are actually IP addresses, both on the LAN (not WAN)
>
> Does anyone see a hidden gotcha that will bite me later?
Someone naming their host &qu
40 matches
Mail list logo
