Anyway.. I found out what the problem is... they don't reply to dnssec
enabled requests...
$ dig +short @ns33.domaincontrol.com. replacementservices.com.
72.32.12.235
$ dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com.
;; connection timed out; no servers could be reached
wan
On Mon, 21 Jun 2010, Rok Potočnik wrote:
Anyway.. I found out what the problem is... they don't reply to dnssec
enabled requests...
$ dig +short @ns33.domaincontrol.com. replacementservices.com.
72.32.12.235
$ dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com.
;; connection
The outgoing "[1au]" queries aren't getting a response. In tcpdump's
display format, I believe "[1au]" means 1 record in the Additional
Section. This would undoubtedly be an OPT record for EDNS0 negotiation.
I'm having no problems querying those same nameservers with EDNS0 by the
way.
What y
What do they mean? I can't find them and yes, I've googled and also
grepped the docs on isc.org ...
I'm assuming it's some way of telling if the query was serviced or not ...
--
Peter Laws / N5UWY
National Weather Center / Network Operations Center
University of Oklahoma Information Technology
On Mon, Jun 21, 2010 at 01:46:55PM -0500, Peter Laws wrote:
> What do they mean? I can't find them and yes, I've googled and also
> grepped the docs on isc.org ...
Googling for symbols isn't easy..
http://www.isc.org/files/arm96.html#the_category_phrase
|The query log entry reports the client's
On Mon, Jun 21, 2010 at 11:46 AM, Peter Laws wrote:
> What do they mean? I can't find them and yes, I've googled and also grepped
> the docs on isc.org ...
>
> I'm assuming it's some way of telling if the query was serviced or not ...
>
Hi Peter,
The following is from the section titled "loggin
On 6/21/2010 2:46 PM, Peter Laws wrote:
What do they mean? I can't find them and yes, I've googled and also
grepped the docs on isc.org ...
I'm assuming it's some way of telling if the query was serviced or not
...
http://www.google.com/search?q=bind+query+log+%22-E%22
(The quotation mar
No, there is no "fast fail" mechanism as you suggest. In a
properly-architected DNS-resolution infrastructure, there are multiple
upstreams configured at every link of the resolution chain. By the time
one link in that chain (e.g. server1) has exhausted all of its upstreams
(server2a, server2b,
On 06/21/10 14:06, Justin T Pryzby wrote:
On Mon, Jun 21, 2010 at 01:46:55PM -0500, Peter Laws wrote:
What do they mean? I can't find them and yes, I've googled and also
grepped the docs on isc.org ...
Googling for symbols isn't easy..
http://www.isc.org/files/arm96.html#the_category_phrase
In message <4c1f85ef.5070...@rula.net>, =?UTF-8?B?Um9rIFBvdG/EjW5paw==?= writes
:
> Anyway.. I found out what the problem is... they don't reply to dnssec
> enabled requests...
>
> $ dig +short @ns33.domaincontrol.com. replacementservices.com.
> 72.32.12.235
>
> $ dig +short +dnssec @ns33.domain
Mark Andrews writes:
>
> In message <4c1f85ef.5070...@rula.net>, =?UTF-8?B?Um9rIFBvdG/EjW5paw==?= writ
> es
> :
> > Anyway.. I found out what the problem is... they don't reply to dnssec
> > enabled requests...
> >
> > $ dig +short @ns33.domaincontrol.com. replacementservices.com.
> > 72.32.12.2
In message <201006220016.o5m0g7j4024...@drugs.dv.isc.org>, Mark Andrews writes:
>
> Mark Andrews writes:
> >
> > In message <4c1f85ef.5070...@rula.net>, =?UTF-8?B?Um9rIFBvdG/EjW5paw==?= wr
> it
> > es
> > :
> > > Anyway.. I found out what the problem is... they don't reply to dnssec
> > > enable
Does anyone else have trouble with this miserable website? Besides the
5 second TTL, it has serious issues resolving on a consistent basis,
and I've tried my workplaces DNS servers through VPN, and BIND going to
the root-servers themselves directly...same results: sporadic resolve
failures.
13 matches
Mail list logo