Hi,
I've been trying to configure bind to use a stub zone, for which I
have keys configured. When I do this, I see a ServFail, with the
logs pointing to:
01-Oct-2009 11:00:03.053 lame-servers: info: not insecure resolving
'xelerance.ca/DNSKEY/IN': 193.110.157.135#53
When I disable the
On 30.09.09 15:59, Sven Eschenberg wrote:
When I had no allow-query statement at all in my config, everything
worked find (includign recursion) for all clients, that were in subnets
directly attached to the server. The external view (authoriative, non
recursive) did work for every client
On 30.09.09 14:59, Louis Luciano (qipman) wrote:
Does anyone know what might be causing these messages?
30-Sep-2009 08:20:56.071 client 10.10.10.10#44554: transfer of
'domain.com/IN': send: socket is not connected
apparently a client that requested transfer but closed connection.
Do you have
Funny enough, I did not have any allow-query at all, but adding
allow-query {any;} did indeed change the behavior. But allow-query-cache
obviously defaults to localhost, localnets and was triggering the
behavior that confused me.
Inbetween I overhauled the config, setting all the options
Hello, I believe I understand what a glue record is, and why I would
need one. I would like some clarification if possible.
While I am not the hugest fan of the dns report services, this report
was brought to my attention:
http://www.intodns.com/hostwizard.com
It says I am missing glue
On 01.10.09 19:10, Sven Eschenberg wrote:
Funny enough, I did not have any allow-query at all, but adding
allow-query {any;} did indeed change the behavior. But allow-query-cache
obviously defaults to localhost, localnets and was triggering the
behavior that confused me.
OK, again: did
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01-Oct-2009, at 16:03, Scott Haneda wrote:
Is it also correct, I only need a NS glue record for the actual NS
itself. There does not need to be a glue record for very zone that
I am providing DNS for?
The only case where glue *must* be
On Oct 1, 2009, at 3:25 PM, Matthew Pounsett wrote:
On 01-Oct-2009, at 16:03, Scott Haneda wrote:
Is it also correct, I only need a NS glue record for the actual NS
itself. There does not need to be a glue record for very zone that
I am providing DNS for?
The only case where glue *must*
In message 200910011237.09...@zmi.at, Michael Monnerie writes:
On Donnerstag 01 Oktober 2009 Mark Andrews wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Specifies which hosts are allowed to =
get answers
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 from the cache. =A0If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01-Oct-2009, at 19:03, Scott Haneda wrote:
So I see my NS is listed in the additional section. This to me
tells me there is in fact glue, so I should consider the report at http://intodns.com/hostwizard.com
to be inaccurate?
Yeah, I just
Hello all,
For the last couple days I've been trying to figure out how to get
dnssec implemented within my environment. A simplified description of my
network is as follows: cloud - Nokia IP330(Check Point) - BigIP F5 -
debian - named.
My problem seems to be that when asking for
In message 73e2882f-00b3-41cb-b46d-351774486...@conundrum.com, Matthew Pounse
tt writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01-Oct-2009, at 19:03, Scott Haneda wrote:
So I see my NS is listed in the additional section. This to me
tells me there is in fact glue, so I
On Fri, 2 Oct 2009, Mark Andrews wrote:
zone ca. IN {
type stub;
masters { 192.228.22.190; 192.228.22.189; };
};
To make the test signed ca work you need to replace the NS RRet
with the names of the nameservers that serve the signed CA zone.
At the moment you end up with
You really want to work out what is being blocked, EDNS?, responses
bigger that 512 bytes? DNSSEC? fragmented responses? With a clean
path all of these should succeed but only the last one won't have
tc set. This does a plain DNS query, a EDNS query that limits
the response to 512 bytes, a
14 matches
Mail list logo
