I'm having trouble resolving uspto.gov with bind 9.6.1-P3 and 9.6-ESV
configured as valdidating resolvers.
Using dig, I get a connection timeout error after a long (~10 sec) delay.
+cdflag provides an immediate response.
state.gov does not get this error. Note that it uses different nameservers
Thank you for your answer.
But this doesn't work: With match-destination and match-clients I can only
define the same match-clients statement for both destionation interfaces, not
differrent one.
The only workaround I see how to rech my goal by only using these commands is
to define a third vi
On Thu, 22 Apr 2010, Timothe Litt wrote:
I'm having trouble resolving uspto.gov with bind 9.6.1-P3 and 9.6-ESV
configured as valdidating resolvers.
Using dig, I get a connection timeout error after a long (~10 sec) delay.
+cdflag provides an immediate response.
Is anyone else seeing this? I
Good day all,
This isn't strictly BIND related, but I think it might have some
relevance to the members of this list.
I am working to document/diagram a very complex BIND deployment
(multiple views, forwards, delegations, servers and environments) and
I'm looking for advice/experience/example
On Thu, Apr 22, 2010 at 10:15 PM, Todd Snyder wrote:
>
> I am working to document/diagram a very complex BIND deployment (multiple
> views, forwards, delegations, servers and environments)
If you can share the document after finishing it we will appreciate
that. Thanks.
--
Jeff Pang
http://h
Am Thu, 22 Apr 2010 10:03:43 -0400 (EDT)
schrieb Paul Wouters :
> On Thu, 22 Apr 2010, Timothe Litt wrote:
>
> > I'm having trouble resolving uspto.gov with bind 9.6.1-P3 and
> > 9.6-ESV configured as valdidating resolvers.
> >
> > Using dig, I get a connection timeout error after a long (~10 sec
On Apr 22 2010, Paul Wouters wrote:
On Thu, 22 Apr 2010, Timothe Litt wrote:
I'm having trouble resolving uspto.gov with bind 9.6.1-P3 and 9.6-ESV
configured as valdidating resolvers.
Using dig, I get a connection timeout error after a long (~10 sec) delay.
+cdflag provides an immediate respo
Looks like the future of the DNSSEC make work project includes resolution
failures here and there. More security - less stability - guaranteed
slavery. I wounder if it's a fair trade.
we'll see ..
regards
joe baptista
On Thu, Apr 22, 2010 at 10:52 AM, Chris Thompson wrote:
> On Apr 22 2010, Pau
So, others are also seeing this, and it's not unique to bind or my corner of
the internet. Thanks.
It seems to have been going on for weeks, so it isn't going to fix itself.
Who do I report this to so that it gets resolved?
FWIW, I tried +vc - from here, it doesn't help. Also, one sometimes
On 4/22/2010 5:30 AM, Tom Schmitt wrote:
>
> Thank you for your answer.
> But this doesn't work: With match-destination and match-clients I can only
> define the same match-clients statement for both destionation interfaces, not
> differrent one.
>
> The only workaround I see how to rech my goa
On Thu, 22 Apr 2010, Chris Thompson wrote:
I have the same problems with our validating unbound instance.
I suspect that this has to do with
dig +dnssec +norec dnskey uspto.gov @dns1.uspto.gov.
dig +dnssec +norec dnskey uspto.gov @sns2.uspto.gov.
failing with timeouts, while dig +dnssec +n
On Thu, Apr 22, 2010 at 08:06:03AM -0400, Timothe Litt wrote:
> I'm having trouble resolving uspto.gov with bind 9.6.1-P3 and 9.6-ESV
> configured as valdidating resolvers.
> [snip]
> Is anyone else seeing this? Ideas on how to troubleshoot?
Not specifically, but I log a lot of errors resolving i
On Thu, Apr 22, 2010 at 11:17 AM, Nate Itkin wrote:
>
> Not specifically, but I log a lot of errors resolving in usps.gov. USPS
> clearly has configuration issues. A representative sample from my logs:
>
> 19-Apr-2010 11:04:23.072 lame-servers: no valid RRSIG resolving '
> EGQ1REIRR8NVE4U6I97RO3P
On 04/22/10 10:23, Paul Wouters wrote:
On Thu, 22 Apr 2010, Chris Thompson wrote:
I have the same problems with our validating unbound instance.
I suspect that this has to do with
dig +dnssec +norec dnskey uspto.gov @dns1.uspto.gov.
dig +dnssec +norec dnskey uspto.gov @sns2.uspto.gov.
faili
Bind Users:
Wonder if anyone has seen this, and can offer an insight? We've recently
installed BIND-9.7.0 onto a server who's configuration under BIND-9.3.6-p1 had
been working AOK. It is a pretty simple 'Split View' server - problem is that a
DIG request on the 'INTERNAL' view - which does
On 4/22/10 8:55 AM, Timothe Litt wrote:
So, others are also seeing this, and it's not unique to bind or my corner of
the internet. Thanks.
It seems to have been going on for weeks, so it isn't going to fix itself.
Who do I report this to so that it gets resolved?
I have had good luck reporti
On Thu, Apr 22, 2010 at 11:36 AM, Michael Sinatra <
mich...@rancid.berkeley.edu> wrote:
> But it doesn't contain the RRSIGs for the DNSKEY. 'dig +norec +cdflag
> dnskey uspto.gov @dns1.uspto.gov' does not contain RRSIGs so it is only
> 1131 bytes. A non-EDNS0 query will receive the TC bit and wi
Dear BIND Users Community,
This is a message about the BIND 10 Mascot contest - and who better to
reach out to than our current users? We hope you'll bear with us
for a moment...
Linux has Tux, the penguin, BSD has its Daemon, ISC's user community
deserves its own little creature to learn to love
On 04/22/10 15:22, Casey Deccio wrote:
Actually, what seems interesting to me is that the cutoff seems to be at a
payload size of 1736, which happens to be the exact size of the complete
response. Is this just coincidence?
Yes it is. With the bufsize set to 1735, the response that will
actu
On Thu, Apr 22, 2010 at 4:25 PM, Michael Sinatra <
mich...@rancid.berkeley.edu> wrote:
> On 04/22/10 15:22, Casey Deccio wrote:
>
> Actually, what seems interesting to me is that the cutoff seems to be at a
>> payload size of 1736, which happens to be the exact size of the complete
>> response.
I get a "connection timed out; no servers could be reached" after the
"Truncated, retrying in TCP mode" even with +bufsiz=512
I am not blocking tcp/53. In fact, telnet dns1.uspto.gov 53 will happily
establish a connection :-) I'm on a fiber (Verizon FiOS business) circuit -
given that others a
In article ,
Paul Wouters wrote:
> On Thu, 22 Apr 2010, Chris Thompson wrote:
>
> >> I have the same problems with our validating unbound instance.
> >
> > I suspect that this has to do with
> >
> > dig +dnssec +norec dnskey uspto.gov @dns1.uspto.gov.
> > dig +dnssec +norec dnskey uspto.gov @s
> Folks on DSL should remember that their magic number is less than 1500 bytes
> (1492 is common, as is 1453).
*Some folks on DSL*. There are definitely DSL networks being operated
with a 1500 byte MTU offered to the user.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
Hi,
To use two instances wouldn't help anything, he would need one instance with
two views and a second instance. Not a big win over three views.
But there is an easy solution with only two views. What the op seemes to have
missed in the docs is the following sentence:
"The order of the view s
In message <394305900.760891271963571419.javamail.r...@sz0093a.westchester.pa.m
ail.comcast.net>, Lou Picciano writes:
> Bind Users:
>
> Wonder if anyone has seen this, and can offer an insight?
BIND 9.7.0 does a better job of detecting anonmallies in responses
to iterative queries. You were j
25 matches
Mail list logo
