In message <52548a5d.3070...@networktest.com>, David Newman writes:
> bind 9.9.4
>
> How to troubleshoot issues when keys are supposed to be invalidated or
> deleted on specific dates, but aren't?
>
> In this case, a KSK was supposed to be inactivated on 29 September 2013
> and deleted on 9 Octo
On 10/8/13 3:51 PM, Alan Clegg wrote:
>
> On Oct 8, 2013, at 6:42 PM, David Newman
> wrote:
>
>> bind 9.9.4
>>
>> How to troubleshoot issues when keys are supposed to be
>> invalidated or deleted on specific dates, but aren't?
>>
>> In this case, a KSK was supposed to be inactivated on 29
>
On Oct 8, 2013, at 6:51 PM, Alan Clegg wrote:
> On Oct 8, 2013, at 6:42 PM, David Newman wrote:
>>
>> Problem is, dig says the key is still active, and will be until 29
>> October 2013:
>>
>> $ dig networktest.com @localhost +multi rrsig | grep 56989
>>
>> 201310
On Oct 8, 2013, at 6:42 PM, David Newman wrote:
> bind 9.9.4
>
> How to troubleshoot issues when keys are supposed to be invalidated or
> deleted on specific dates, but aren't?
>
> In this case, a KSK was supposed to be inactivated on 29 September 2013
> and deleted on 9 October 2013.
>
> Fro
On Oct 8, 2013, at 6:31 PM, Steven Carr wrote:
> On 8 October 2013 23:27, Alan Clegg wrote:
>> Except for using your servers to find the root servers to begin with.
>
> I stand corrected, I thought it might have done something clever for
> the first hop and had the root hints compiled in.
Thi
bind 9.9.4
How to troubleshoot issues when keys are supposed to be invalidated or
deleted on specific dates, but aren't?
In this case, a KSK was supposed to be inactivated on 29 September 2013
and deleted on 9 October 2013.
>From the .key file:
; This is a key-signing key, keyid 56989, for netw
On 8 October 2013 23:27, Alan Clegg wrote:
> Except for using your servers to find the root servers to begin with.
I stand corrected, I thought it might have done something clever for
the first hop and had the root hints compiled in.
Steve
___
Please v
On Oct 8, 2013, at 5:39 PM, Steven Carr wrote:
> +trace ALWAYS goes to the root servers. It will bypass your DNS server
> completely.
Except for using your servers to find the root servers to begin with.
AlanC
--
Alan Clegg | +1-919-355-8851 | a...@clegg.com
signature.asc
Description: Mess
In message , Con Wieland writes:
>
> On Oct 8, 2013, at 2:13 PM, Mark Andrews wrote:
>
> >=20
> > In message <93fdc4db-8835-482d-8b7d-7b58d09d5...@uci.edu>, Con Wieland =
> writes:
> >> I am still trying to understand the empty zones and bind 9.8.5-P2
> >> behaviour. The default shows 332 zones.
+trace ALWAYS goes to the root servers. It will bypass your DNS server
completely.
Steve
On 8 October 2013 22:37, Con Wieland wrote:
>
> On Oct 8, 2013, at 2:13 PM, Mark Andrews wrote:
>
>>
>> In message <93fdc4db-8835-482d-8b7d-7b58d09d5...@uci.edu>, Con Wieland
>> writes:
>>> I am still tryi
On Oct 8, 2013, at 2:13 PM, Mark Andrews wrote:
>
> In message <93fdc4db-8835-482d-8b7d-7b58d09d5...@uci.edu>, Con Wieland writes:
>> I am still trying to understand the empty zones and bind 9.8.5-P2
>> behaviour. The default shows 332 zones. With empty-zones-enable no; I
>> get 253 zones, but
In message <93fdc4db-8835-482d-8b7d-7b58d09d5...@uci.edu>, Con Wieland writes:
> I am still trying to understand the empty zones and bind 9.8.5-P2
> behaviour. The default shows 332 zones. With empty-zones-enable no; I
> get 253 zones, but with empty-zones-enable yes: I get 349
>
> The difference
So a "dig 10.IN-ADDR-ARPA" hasn't queried the root at all, if it had
you would have a response with an SOA of prisoner.iana.org and you
wouldn't have got an NXDOMAIN.
sjcarr@elmo:~ $ dig 10.in-addr.arpa
; <<>> DiG 9.8.5-P1 <<>> 10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<
On Tue, Oct 08, 2013 at 09:42:10AM +1100, Mark Andrews wrote:
>
>In message <52528314.4010...@z74.net>, Maurice Janssen writes:
>> The problem is that after some time Bind seems to loose track of the
>> keys for most of the zones.
>> At this moment, only one of the zones is OK:
>>
>> # rndc signi
I am still trying to understand the empty zones and bind 9.8.5-P2 behaviour.
The default shows 332 zones. With empty-zones-enable no; I get 253 zones, but
with empty-zones-enable yes: I get 349
The difference between empty zones yes and no is the addition of zones:
10.IN-ADDR.ARPA
& 16.172.IN
On 08.10.13 11:49, John Wobus wrote:
We received a report that a domain we serve
was not resolving at a remote site. The site
also reported their own analysis that the issue
appeared to be that the domain's NS record had
a longer TTL than its target nameserver's
A record and their caching server
Hi John,
El 2013-10-08 11:49:24, John Wobus escribió:
> They took responsibility for their
> nameserver's deficiency, but it
> makes me wonder:
> -Is this addressed by a standard? E.g.,
> the nameserver's A record have the same
> TTL as NS records pointing at it.
> -Is this addressed by a "best
We received a report that a domain we serve
was not resolving at a remote site. The site
also reported their own analysis that the issue
appeared to be that the domain's NS record had
a longer TTL than its target nameserver's
A record and their caching server didn't
seem able to handle this. FYI
On 10/08/2013 12:54 AM, Jim Pazarena wrote:
I have a client who has been assigned a /20 from ARIN.
They asked me to help them with their DNS.
The DNS for me is the easy part. except...
ARIN has told them that you use the DNS to set up the routing so that
the traffic for this /20 gets routed to
19 matches
Mail list logo
