In message <5203ca6c.9000...@corp.sonic.net>, Grant Keller writes:
> On 08/08/2013 09:34 AM, Phil Mayers wrote:
> > On 08/08/13 17:22, Grant Keller wrote:
> >
> >> Its strange, I get the records when querying one of my other DNS
> >> servers:
> >
> > As per my original email - firewall? middlebox?
On 08/08/2013 09:34 AM, Phil Mayers wrote:
> On 08/08/13 17:22, Grant Keller wrote:
>
>> Its strange, I get the records when querying one of my other DNS
>> servers:
>
> As per my original email - firewall? middlebox? crazy ISP transparent
> caching DNS server?
>
> I would break out tcpdump; clear
On 08/08/13 17:22, Grant Keller wrote:
Its strange, I get the records when querying one of my other DNS servers:
As per my original email - firewall? middlebox? crazy ISP transparent
caching DNS server?
I would break out tcpdump; clear the cache on the affected server, re-do
the dig, then
On 08/08/2013 09:09 AM, Alan Clegg wrote:
> On Aug 8, 2013, at 11:58 AM, Grant Keller wrote:
>
>> # dig +dnssec +cd zygo.com a
>>
>> ; <<>> DiG 9.7.0-P2-RedHat-9.7.0-17.P2.el5_9.2 <<>> +dnssec +cd zygo.com a
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOE
On Aug 8, 2013, at 11:58 AM, Grant Keller wrote:
> # dig +dnssec +cd zygo.com a
>
> ; <<>> DiG 9.7.0-P2-RedHat-9.7.0-17.P2.el5_9.2 <<>> +dnssec +cd zygo.com a
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45711
> ;; flags: qr rd ra cd; QUERY: 1
On 08/07/2013 06:17 PM, Mark Andrews wrote:
>>> In any event, as Mark has suggested, you don't want to dig the RRSIG
>>> yourself. Rather, use:
>>>
>>> dig +dnssec zygo.com a
>>>
>>> ...and if you get a SERVFAIL:
>>>
>>> dig +dnssec +cd zygo.com a
>> dig +dnssec +cd zygo.com a resolved the domain.
> > In any event, as Mark has suggested, you don't want to dig the RRSIG
> > yourself. Rather, use:
> >
> > dig +dnssec zygo.com a
> >
> > ...and if you get a SERVFAIL:
> >
> > dig +dnssec +cd zygo.com a
> dig +dnssec +cd zygo.com a resolved the domain.
"RESOLVED THE DOMAIN" is not !@#$#!$!@#!$@#
On 08/07/2013 01:53 AM, Phil Mayers wrote:
> On 08/07/2013 12:09 AM, Grant Keller wrote:
>> Hello,
>>
>> We have 7 recursive DNS servers running Bind 9.9.2, and we are seeing
>> some strange behavoir validating DNSSEC. We have seen this happen a few
>> times, and in the past the problem has gone aw
On 08/07/2013 12:09 AM, Grant Keller wrote:
Hello,
We have 7 recursive DNS servers running Bind 9.9.2, and we are seeing
some strange behavoir validating DNSSEC. We have seen this happen a few
times, and in the past the problem has gone away when the server is
rebooted, so my first guess is that
When diagnosing DNSSEC problems you need to chase the trust chain
from DS record to the DNSKEY RRset to the answer RRset.
; <<>> DiG 9.10.0pre-alpha <<>> ds zygo.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65065
;; flags: qr rd ra ad; QUE
I haven't had a chance to sit down an fully investigate however a few
weeks ago I was forced to disable dnssec on the nac.net zone. We use
inline signing and for whatever reason our secondary (ns2) machine was
giving out stale copies of the zone. Nuking the zone and related files,
restarting
Hello,
We have 7 recursive DNS servers running Bind 9.9.2, and we are seeing
some strange behavoir validating DNSSEC. We have seen this happen a few
times, and in the past the problem has gone away when the server is
rebooted, so my first guess is that some record is stuck in the cache.
An example
12 matches
Mail list logo
