Hello,
Do add "forward only;" to this zone statement.
Is this name server available/visible to the Internet ?
--> add "allow-query" statement to limit who can query for your internal
zone.
Kind regards,
Marc Lampo
Security Officer
EURid
-Original Message-
From: CT [mailto:gro...@obsd
I think I found the reason why dig +trace always failed with a timeout.
From the announcement of Bind 9.8.1 from earlier today:
* If the server has an IPv6 address but does not have IPv6
connectivity to the internet, dig +trace could fail attempting to
use IPv6 addresses. [RT #
Hello,
I found that some queries have got the response which has additional
section, but some haven't.
For example, this query with www.google.com got the answer with
additional section set:
$ dig www.google.com
; <<>> DiG 9.6.1-P2 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->
Introduction
BIND 9.8.1 is the current production release of BIND 9.8.
This document summarizes changes from BIND 9.8.0 to BIND 9.8.1. Please
see the CHANGES file in the source code release for a complete list of
all changes.
Download
The latest versions of BIND 9 software can
We have a public DNS in our DMZ
- Some of the servers in the DMZ provide certain services to services on
the
inside.
- Currently, certain servers use the Internal AD DNS Servers for resolution
on a internal DNS domain to provide the services via firewall rules.
I would like all DMZ clients to
> >> What strikes me as odd is that the first query does return 4 (internal)
> >> root servers, but no glue records ?
> >
> >I have no idea why this is this way.
>
> Because +trace only displays the answer section of the responses by
> default.
> Try "dig +trace +additional".
Hi Chris,
you are
Original-Nachricht
> I believe what is missing the root cache file.
>
> The root server would have glue records point to GTLDs, like this
>
> Then the GTLDs would have glue records pointing to nameserver of the
> domain you are trying to trace.
>
> What you are seeing is yo
Lyle Giese wrote on 2011-08-31:
> On 8/31/2011 8:40 AM, Florian CROUZAT wrote:
>> Florian CROUZAT wrote on 2011-08-25:
>>
>>> Hi list,
>>>
>>> On a few domains (we'll consider only one domain for this example) I
>>> encounter sometimes (seemingly randoms) ServFails while resolving
>>> domain names
On 8/31/2011 8:40 AM, Florian CROUZAT wrote:
Florian CROUZAT wrote on 2011-08-25:
Hi list,
On a few domains (we'll consider only one domain for this example) I
encounter sometimes (seemingly randoms) ServFails while resolving domain
names. A client (192.168.147.2) asks my caching server (192.1
Florian CROUZAT wrote on 2011-08-25:
> Hi list,
>
> On a few domains (we'll consider only one domain for this example) I
> encounter sometimes (seemingly randoms) ServFails while resolving domain
> names. A client (192.168.147.2) asks my caching server (192.168.151.100)
> to resolve a target (www.
On Tue, Aug 30, 2011 at 9:26 AM, TMK wrote:
>
> On Tue, Aug 30, 2011 at 6:55 AM, Mark Andrews wrote:
>>
>> In message
>> ,
>> TMK writes:
>>> Dears,
>>>
>>> Probably this the thousand time you get these question. but our bind server
>>> have slow response time for the non-cached entries.
>>>
>
On Aug 31 2011, Tom Schmitt wrote:
What strikes me as odd is that the first query does return 4 (internal)
root servers, but no glue records ?
I have no idea why this is this way.
Because +trace only displays the answer section of the responses by default.
Try "dig +trace +additional".
--
C
Hi Michael!
Am 30.08.2011 20:33, schrieb Michael Graff:
> On 2011-08-30 12:06 PM, Klaus Darilion wrote:
>
>> Unfortunately I fail to find the options where I can configure the
>> number of retransmissions, timeouts and number of transactions -
>> please give me some hints.
>
> I don't believe t
I believe what is missing the root cache file. The root cache file would
something like this.
; <<>> DiG 9.7.4b1-RedHat-9.7.4-0.3.b1.fc14 <<>> +trace valhalla.stsci.edu
;; global options: +cmd
. 132693 IN NS c.root-servers.net.
. 132693 IN
14 matches
Mail list logo
