I guess not, since it does not work ;-)
After deleting all entries, did you :
1) dig @dns.name. ...
or
2) dig @IP.address
or
3) No @... argument used at all ?
In cases 1 3, dig will need data from /etc/resolv.conf.
Only in case 2 dig can do without.
Kind regards,
Marc Lampo
-Original
at least from my point dig hostname +trace should work even if there
is no resolv.conf entries.
On Tue, Jul 19, 2011 at 1:39 PM, Marc Lampo marc.la...@eurid.eu wrote:
I guess not, since it does not work ;-)
After deleting all entries, did you :
1) dig @dns.name. ...
or
2) dig @IP.address
On Tue, Jul 19, 2011 at 12:32 PM, Feng He short...@gmail.com 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,
what makes you think that? From the man page
dig (domain information
On Tue, Jul 19, 2011 at 1:50 PM, Marc Lampo marc.la...@eurid.eu 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 work
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 b...@jubileegroup.co.uk 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
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
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
On Tue, Jul 19, 2011 at 11:40:02AM +0200,
pa...@laposte.net 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
On 7/19/2011 1:16 AM, Feng He wrote:
On Tue, Jul 19, 2011 at 1:50 PM, Marc Lampomarc.la...@eurid.eu 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
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
On 7/19/11 9:30 AM, almah...@ranksitt.net 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
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
On Tue, Jul 19, 2011 at 08:30:17PM +0600,
almah...@ranksitt.net 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
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=
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 particular
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 @server... 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
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
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
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
24 matches
Mail list logo
