In article ,
Mark Andrews wrote:
> If it is not a local DPI problem then the only other thing
> is that domaincontrol.com in using anycast and one or more
> of the sites is using using nameservers that don't respond
> to EDNS queries or has a firewall that blocks EDNS que
If it is not a local DPI problem then the only other thing
is that domaincontrol.com in using anycast and one or more
of the sites is using using nameservers that don't respond
to EDNS queries or has a firewall that blocks EDNS queries.
Mark
% traceroute -
Another datapoint:
dig +dnssec @ns33.domaincontrol.com. replacementservices.com.
; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec @ns33.domaincontrol.com.
replacementservices.com.
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
silver3:~ carlsen$ dig +dnssec
On Wed, Jun 23, 2010 at 05:25:31PM +0200, Warren Kumari wrote:
> >>
> >> # dig +dnssec @ns33.domaincontrol.com. replacementservices.com.
> >
> > Since it's working quite okay for several locations on here, the
> > problem may be found somewhere in between sites.
> >
> > I personally don't get any f
On Jun 23, 2010, at 2:41 PM, Torsten wrote:
Am Wed, 23 Jun 2010 11:01:29 +0200
schrieb Erwin Lansing :
On Wed, Jun 23, 2010 at 05:51:24PM +1000, Mark Andrews wrote:
In message
,
Piff writes:
Mark,
more than once you have blamed firewal but I have tested without
firewall and NSxx.DOMAINCON
On 23.06.10 14:41, Torsten wrote:
> Since it's working quite okay for several locations on here, the
> problem may be found somewhere in between sites.
>
> I personally don't get any failures with the dig statement from above
> no matter how often I try.
>
> Looking at a tracepath the last hop I
Am Wed, 23 Jun 2010 11:01:29 +0200
schrieb Erwin Lansing :
> On Wed, Jun 23, 2010 at 05:51:24PM +1000, Mark Andrews wrote:
> >
> > In message
> > ,
> > Piff writes:
> > > Mark,
> > >
> > > more than once you have blamed firewal but I have tested without
> > > firewall and NSxx.DOMAINCONTROL.COM
On 23.06.2010 / 17:51:24 +1000, Mark Andrews wrote:
>
> In message ,
> Piff
> writes:
> > Mark,
> >
> > more than once you have blamed firewal but I have tested without
> > firewall and NSxx.DOMAINCONTROL.COM do not answer to "dig +dnssec".
>
> Wrong. The nameserver DO answer these queries.
>
On Wed, Jun 23, 2010 at 11:23:51AM +0200, Matus UHLAR - fantomas wrote:
>
> works for me, works for mark... the problem is apparently not on their side.
> I have tried more times when reading this thread. I'm also curious where the
> problem could be.
>
All I know is that "something" changed last
> On Wed, Jun 23, 2010 at 05:51:24PM +1000, Mark Andrews wrote:
> > Wrong. The nameserver DO answer these queries.
On 23.06.10 11:01, Erwin Lansing wrote:
> Right, unfortunately. All is fine on a freshly reloaded bind, but after
> a while no answers are seen. This is on Bind 9.4, 9.5 and 9.6.
On Wed, Jun 23, 2010 at 05:51:24PM +1000, Mark Andrews wrote:
>
> In message ,
> Piff
> writes:
> > Mark,
> >
> > more than once you have blamed firewal but I have tested without
> > firewall and NSxx.DOMAINCONTROL.COM do not answer to "dig +dnssec".
>
> Wrong. The nameserver DO answer these
In message , Piff
writes:
> Mark,
>
> more than once you have blamed firewal but I have tested without
> firewall and NSxx.DOMAINCONTROL.COM do not answer to "dig +dnssec".
Wrong. The nameserver DO answer these queries.
# dig +dnssec @ns33.domaincontrol.com. replacementservices.com.
; <<>> D
Mark,
more than once you have blamed firewal but I have tested without
firewall and NSxx.DOMAINCONTROL.COM do not answer to "dig +dnssec".
The real problem is bind. Freshly reloaded bind will do a query with
OPT EDNS0 set and after a timeout retry the query without OPT EDNS0
but
after some time
On Mon, Jun 21, 2010 at 05:31:59PM +0200, 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. replac
On 22.6.2010 2:16, Mark Andrews wrote:
I suspect that your firewall is dropping replies to EDNS queries
that *don't* include the OPT record (i.e. they are plain DNS not
EDNS responses). Note that there was no OPT record in the reply.
I hardly think that my firewall configuration is faulty bec
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
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 <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
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
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
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
I have same problem too...
I can't get normal dns result's.
For a temporary fixing problem I use forwarding on my ns2 server, and I use
opendns service.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-use
I'm using bind 9.7.0-p2 as an authoritive/caching server on a couple of
servers and lately I'm noticing that we're having problems resolving
domains under *.domaincontrol.com servers. The query itself is sent out
(as the tcpdump output down below shows) but only a couple of replies
get back. In
23 matches
Mail list logo
