> "dig +trace" calls getaddrinfo() and that needs to be able to resolve
> the hostname (without dots at the end). getaddrinfo() is called
> so that we don't have to have a full blown iterative resolver in
> dig.
>
I see. So no way to solve this one in dig itself.
> The Internet moved from bei
> > In my case, dig is asking for the nameservers of the root-zone and is
> > getting the answer:
> > . IN NS root1
> > . IN NS root2
> > etc
> >
> > Next dig is asking for the A-record of root1. And here is the
> > differrence:
> >
> > If I do "dig root1" dig is asking exactly this, it is ask
On 01.09.2011 19:01, CT wrote:
so did you end up setting up a slave zone (for the internal AD DNS) on
your public DNS server ?
No, for now I just left the AD DNS (Microsoft DNS) instead of BIND. I
didn't have time to move all DNS servers to BIND and make them
primary/slave for locale zone.
_
On 09/01/2011 21:23, 风河 wrote:
> i just want to make sure about it,
The rules for what is and is not included in the ADDITIONAL section are
not only not strict, they vary from server to server, and sometimes they
vary with different versions of the same server.
> and will the client resolver use
i just want to make sure about it, and will the client resolver use the
additional records directly?
在 2011-9-2 下午12:06，"Doug Barton" 写道：
> On 09/01/2011 20:45, 风河 wrote:
>> But why this named does returned additional section?
>
> Rather than focusing on the additional section in dig responses, may
On 09/01/2011 20:45, 风河 wrote:
> But why this named does returned additional section?
Rather than focusing on the additional section in dig responses, maybe
you can describe what problem you're trying to solve.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
In message
, =?UTF-8?B?6aOO5rKz?= writes:
> On Fri, Sep 2, 2011 at 11:36 AM, Mark Andrews wrote:
>
> > Named doesn't return records tagged as additional in the additional
> > section. Â This stops the propogation of bogus records. Â Note there
> > is no requirement for additional records to be
On Fri, Sep 2, 2011 at 11:36 AM, Mark Andrews wrote:
> Named doesn't return records tagged as additional in the additional
> section. This stops the propogation of bogus records. Note there
> is no requirement for additional records to be added ever. Glue
> records are not additional records e
In message
, =?UTF-8?B?6aOO5rKz?= writes:
> 2011/9/1 Daniel McDonald :
> > On 8/31/11 10:13 PM, "é£æ²³" wrote:
> >
> >> 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
2011/9/1 Daniel McDonald :
> On 8/31/11 10:13 PM, "风河" wrote:
>
>> 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.co
In message <4e5fb1ab.4040...@data.pl>, Torinthiel writes:
> On 09/01/11 17:56, Tom Schmitt wrote:
> >=20
> > I found the cause of my problem (and a solution):
> >=20
> > dig +trace actually has another behaviour than doing the trace manually=
> step by step with dig.
> >=20
> >=20
> > For a trace
On 09/01/11 17:56, Tom Schmitt wrote:
>
> I found the cause of my problem (and a solution):
>
> dig +trace actually has another behaviour than doing the trace manually step
> by step with dig.
>
>
> For a trace, dig is asking for the NS-records, then for the IP-address of the
> nameserver fou
On 09/01/2011 07:59 AM, Vbvbrj wrote:
I had the same question a while ago. Using bind with forward only to an
AD DNS will get to errors for infrastructure, because of BIND caching
unable to disable for this forwarded zone. Also BIND does not redirect
all updates queries to AD DNS, while in an AD
I found the cause of my problem (and a solution):
dig +trace actually has another behaviour than doing the trace manually step by
step with dig.
For a trace, dig is asking for the NS-records, then for the IP-address of the
nameserver found and then go on asking this nameserver. Till the desti
On 8/31/11 10:13 PM, "风河" wrote:
> 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
> ;; MSG SIZE rcvd: 236
> $ dig w
I had the same question a while ago. Using bind with forward only to an
AD DNS will get to errors for infrastructure, because of BIND caching
unable to disable for this forwarded zone. Also BIND does not redirect
all updates queries to AD DNS, while in an AD environment updates are
made very often
I spoke too soon :-(
>
> 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
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...@
Dear all,
We are running bind since more than 10 years. Allways the latest version.
Now we observe the problem, that dynamic entries, which are in the jrl File and
not in the zone file, are not transfered, or notifyed to the slave.
When I do a rndc freeze zone / unfreeze. The tranfere is working
19 matches
Mail list logo
