Hi,
I need to setup an A record for a machine who's IP might change
unexpectedly, and I need to ensure PCs out there cache it for as short
a time as possible:
host1300 IN A 10.10.10.10
Does anyone know whether MS windows PCs will in fact honour that 300s,
then force a re-lookup? Can I
Am 13.02.2012 um 19:48 schrieb Axel Rau:
> ere is the next revision with comments from Mark and Jeff incorporated (same
> URL):
>
> https://www.chaos1.de/svn-public/repos/network-tools/DNSsec/trunk/dnssec_key_states.pdf
> I'm still unsure about submitting the follow-up DS while its KSK no
On Tue, Feb 14, 2012 at 5:59 AM, goran kent wrote:
> Hi,
>
> I need to setup an A record for a machine who's IP might change
> unexpectedly, and I need to ensure PCs out there cache it for as short
> a time as possible:
>
> host1 300 IN A 10.10.10.10
>
> Does anyone know whether MS windows
Dear Team,
We have a Authenticated Response in DNSSEC through trust chain.
Now my question is why we itself need a NSEC when we get response from
DNSSEC enabled server authentically.
Means, if a Record exist in DNSSEC, then it replies the answer along with
RRSIG of that RR.
AND if domain
[ Quoting at 22:53 on Feb 14 in "Query Regarding
NSEC..." ]
> Dear Team,
>
> We have a Authenticated Response in DNSSEC through trust chain.
>
> Now my question is why we itself need a NSEC when we get response from DNSSEC
> enabled server authentically.
>
>
>
> Means, if a Record exist in
> We have a Authenticated Response in DNSSEC through trust chain.
> Now my question is why we itself need a NSEC when we get response from DNSSEC
> enabled server authentically.
> Means, if a Record exist in DNSSEC, then it replies the answer along with
> RRSIG of that RR.
> AND if domain doesn
On Feb 14, 2012, at 2:59 AM, goran kent wrote:
> I need to setup an A record for a machine who's IP might change
> unexpectedly, and I need to ensure PCs out there cache it for as short
> a time as possible:
>
>host1300 IN A 10.10.10.10
>
> Does anyone know whether MS windows PCs will in
Hi,
I have a fedora16 x86_64 box and named keeps dying with an assertion failure:
14-Feb-2012 13:24:41.137 general: critical: rbtdb.c:1619:
INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
14-Feb-2012 13:24:41.137 general: critical: exiting (due to assertion failure)
This is bin
On 2/14/2012 1:42 PM, Chuck Swiger wrote:
> ISC's BIND has (or had) a MINTTL value of 5 minutes / 300 seconds.
> It's probably unreasonable to expect other platforms to refetch DNS
> records faster than that.
Uh... no. BIND has always respected TTL when caching information.
AlanC
--
a...@clegg
Briefly, the answer is, the NXDOMAIN response could be replayed by a
man-in-the-middle attacker. We need to have something to sign, something
specific to that query. If we just return the zone's SOA record and its
signature, we're still subject to a replay attack. So we need to prove the
negati
Mac OS X imposes a 60 second minimum on TTLs, or at least it did at one time. I
am unaware of any other client OS having such a restriction.
Client software does not always respect TTLs, though. It's entirely possible
for a client application to completely ignore the TTL value and continue to
c
On Feb 14, 2012, at 11:11 AM, Alan Clegg wrote:
> On 2/14/2012 1:42 PM, Chuck Swiger wrote:
>
>> ISC's BIND has (or had) a MINTTL value of 5 minutes / 300 seconds.
>> It's probably unreasonable to expect other platforms to refetch DNS
>> records faster than that.
>
> Uh... no. BIND has always re
On Feb 14, 2012, at 11:23 AM, Chuck Swiger wrote:
On Feb 14, 2012, at 11:11 AM, Alan Clegg wrote:
>> On 2/14/2012 1:42 PM, Chuck Swiger wrote:
>>
>>> ISC's BIND has (or had) a MINTTL value of 5 minutes / 300 seconds.
>>> It's probably unreasonable to expect other platforms to refetch DNS
>>> recor
Hello Gaurav,
You might want to have a look at our whitepaper on 'authenticated denial
of existence' to gain better understanding of this somewhat complicated
aspect of the DNSSEC specification:
https://www.sidn.nl/fileadmin/docs/PDF-files_UK/wp-2011-0x01-v2.pdf
Regards,
--
Marco
On 02/14/20
It is a known issue, and is indeed a bug. We're working on it already, so stay
tuned.
--Michael
On Feb 14, 2012, at 12:44 PM, Alex wrote:
> Hi,
>
> I have a fedora16 x86_64 box and named keeps dying with an assertion failure:
>
> 14-Feb-2012 13:24:41.137 general: critical: rbtdb.c:1619:
> IN
In message <0b215138-0162-4fe0-835a-9fc611a6e...@mac.com>, Chuck Swiger writes:
> On Feb 14, 2012, at 2:59 AM, goran kent wrote:
> > I need to setup an A record for a machine who's IP might change
> > unexpectedly, and I need to ensure PCs out there cache it for as short
> > a time as possible:
>
On Feb 14, 2012, at 2:16 PM, Mark Andrews wrote:
>> ISC's BIND has (or had) a MINTTL value of 5 minutes / 300 seconds.
>> It's probably unreasonable to expect other platforms to refetch DNS
>> records faster than that.
>
> To the best of my knowlege this is just plain wrong.
Look at BIND-4.8.3 a
In message <4a96bb45-eacb-4252-89c6-34061849c...@mac.com>, Chuck Swiger writes:
> On Feb 14, 2012, at 2:16 PM, Mark Andrews wrote:
> >> ISC's BIND has (or had) a MINTTL value of 5 minutes / 300 seconds.
> >> It's probably unreasonable to expect other platforms to refetch DNS
> >> records faster th
Hi All
For My internal DNS setup i want to create a internal root hint file .
Should i follow the pattern of standard root hint file ?
Thanks & Regards
Vishesh Kumar
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
fr
19 matches
Mail list logo
