With "+trace" it still needs to know the list of root name servers to get
started.
Since that list is not built-in, it has to ask the local caching name
server;
as configured per /etc/resolv.conf ...
(the list cannot be built-in, because some organisations work with an
internal
root. The loca
On Tue, Jul 19, 2011 at 1:50 PM, Marc Lampo wrote:
> the list cannot be built-in, because some organisations work with an
> internal
> root. The local caching name server is the only one to know those "new"
> root's.)
>
I don't think so.
BIND 9 has the built-in root list.
__
Hi there,
On Tue, 19 Jul 2011 wrote:
> When I deleted all the entries in /etc/resolv.conf (I am using
> Linux), dig can't work.
>
> I was thinking since dig is a standard resolver...
man resolv.conf
" If this file doesn't exist the only name server to be queried will be on the
local machine
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am very interested in hearing what you are looking for. I have some
thoughts about "performance" measurements, mostly to answer the age-old
question, "Are my servers working well?"
Would you release the patches, and if so, would you be willing to w
Hello,
I want to make sure that if the authoritative server won't cache anything even
if the authoritative answer from itself? Coz I saw the book Pro DNS and BIND
says: The (authoritative) name server does not cache.
thanks.
Une messagerie gratuite, garantie à vie et des services en plus, ça
On Tue, Jul 19, 2011 at 2:47 PM, G.W. Haywood wrote:
>
> man resolv.conf
>
> " If this file doesn't exist the only name server to be queried will be on
> the local machine; the domain name is determined from the
> hostname and the domain search path is constructed from the domain
> name.
On 07/19/2011 06:32 AM, Feng He wrote:
Hi list,
When I deleted all the entries in /etc/resolv.conf (I am using Linux),
dig can't work.
I was thinking since dig is a standard resolver, it should have the
capibility to follow the referrel from root, thus it will work fine
even there is no system d
On 2011-07-19 11:40, pa...@laposte.net wrote:
Hello,
I want to make sure that if the authoritative server won't cache
> anything even if the authoritative answer from itself? Coz I saw
> the book Pro DNS and BIND says: The (authoritative) name server
> does not cache.
Authoritative server can
On Tue, Jul 19, 2011 at 11:40:02AM +0200,
pa...@laposte.net wrote
a message of 11 lines which said:
> I want to make sure that if the authoritative server won't cache
> anything even if the authoritative answer from itself?
I'm sorry but this sentence seems quite difficult to parse.
On 7/19/2011 1:16 AM, Feng He wrote:
On Tue, Jul 19, 2011 at 1:50 PM, Marc Lampo wrote:
the list cannot be built-in, because some organisations work with an
internal
root. The local caching name server is the only one to know those "new"
root's.)
I don't think so.
BIND 9 has the built-in
Hi,
If Bind version of primary dns is "bind-libs-9.3.6-16.P1.el5" and for
secondary dns "bind-9.5.0-29.b2.fc9.i386".
Is there create any problem?? Is it mandatory the same version for
primary and secondary DNS.
Regards -
Mahmud
___
Please visit htt
On 7/19/11 9:30 AM, "almah...@ranksitt.net" wrote:
> Hi,
>
> If Bind version of primary dns is "bind-libs-9.3.6-16.P1.el5" and for
> secondary dns "bind-9.5.0-29.b2.fc9.i386".
>
> Is there create any problem??
In general, it creates no problem. If you happen to use an RR for which
support wa
Feng:
I think G.W is pointing out that in the absence of resolv.conf, dig uses
the localhost to connect
to the bind server. Just tcpdump the loopback interface, and you will
see it.
So the reason resolution works is because you are running bind on that
server. It would not work
on any client wh
On Tue, Jul 19, 2011 at 08:30:17PM +0600,
almah...@ranksitt.net wrote
a message of 18 lines which said:
> Is it mandatory the same version for primary and secondary DNS.
It is not even mandatory for all the authoritative name servers to run
BIND. They can be of different brands. That's the be
All,
anyone experiencing the same behavior?
Seen on
BIND 9.5.2-P2 and BIND 9.8.0-P4
ns11:~ # nslookup -querytype=A xserv.ins.dell.com.
.
Non-authoritative answer:
Name: xserv.ins.dell.com
Address: 143.166.148.118
All ok.
ns11:~ # nslookup -querytype= xserv.ins.dell.com.
> If Bind version of primary dns is "bind-libs-9.3.6-16.P1.el5" and for
> secondary dns "bind-9.5.0-29.b2.fc9.i386".
Something wrong there: "libs" vs. "server", but I assume you mean server
for both.
> Is it mandatory the same version for
> primary and secondary DNS.
Not unless you rely on a pa
Or as previously pointed out it WILL work if you specify a name server at
invocation.
That is to say you MUST either do "dig @..." OR have a resolve.conf
that specifies servers to attempt if not specified at invocation. (And before
anyone else says it - You can of course still specify a serve
On Tue, Jul 19, 2011 at 04:58:53PM +0200, mailsecurity wrote:
> All,
>
> anyone experiencing the same behavior?
I hope so, because that's the correct behavior. Dell's nameserver is broken:
http://tools.ietf.org/html/rfc4074
Common Misbehavior Against DNS Queries for IPv6 Addresses - May 2005
4.2
This is because Dell has incorrectly configured their F5 GTM load
balancers to return NXDOMAIN on a query instead of NOERROR (this
is configurable on a per-wideip basis in the GTM configuration - at
least in present versions. In earlier versions you had to ensure that
you had a record of some
On Jul 19 2011, mailsecurity wrote:
All,
anyone experiencing the same behavior?
Seen on
BIND 9.5.2-P2 and BIND 9.8.0-P4
ns11:~ # nslookup -querytype=A xserv.ins.dell.com.
.
Non-authoritative answer:
Name: xserv.ins.dell.com
Address: 143.166.148.118
All ok.
ns11:~ # nslookup -queryty
Will escalate via our Dell contact. Keep you posted about my success.
Regards,
Patrick
--
This e-mail message and any attachments are of a confidential nature. The
information is intended for the named addressee exclusively. If you are not the
addressee, you may not electronically disseminate,
On 7/18/2011 11:42 PM, AMANI MOHAMED BIN SUWAIF wrote:
Hi,
I have the below scenario
_TCP.EXAMPLE.COMIN SRV1005060primary-sbg.example.com
_TCP.EXAMPLE.COMIN SRV2005060
secondary-sbg.example.com
I have 2 IP ranges and 2 SBGs host, my intention is
for cl
Hi,
The problem is that fail-over between A records is not standard and
might/might not work with various SIP clients. On the other hand SRV in
my opinion has been designed with that in mind, that's why the
additional complexity with 2 SRV records.
Thanks & Regards,
*Amani*
On 7/20/2011
Hi guys,
I recently implemented an ordering of my own by providing an option similar
to random and cyclic in the 'towiresorted' function and setting that order
in the named.conf file by using rrset-order. The named binary is running
fine and giving me the correct result while i use dig for eg. dig
24 matches
Mail list logo