On 08/20/2018 10:14 AM, Lee wrote:
On 8/19/18, Mark Andrews wrote:
nslookup applies the search list by default and doesn’t stop on a NODATA
response.
Some versions of nslookup have been modified by OS vendors to use /etc/hosts
for address lookups.
nslookup doesn’t display the entire response
Lee wrote:
>
> So... it seems like the bottom line is that dig is better but nslookup
> ain't all that bad
Be careful though, all bets are off if you find yourself using something
that claims to be nslookup but which isn't the BIND9 version.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
North
On 8/19/18, Mark Andrews wrote:
> nslookup applies the search list by default and doesn’t stop on a NODATA
> response.
>
> Some versions of nslookup have been modified by OS vendors to use /etc/hosts
> for address lookups.
>
> nslookup doesn’t display the entire response by default.
I learned som
And don't forget NIS, and NSSwitch. And don't get me started on the
tricks that the windows resolver plays.
On 08/19/2018 07:59 PM, Mark Andrews wrote:
nslookup applies the search list by default and doesn’t stop on a NODATA
response.
Some versions of nslookup have been modified by OS vendors
nslookup applies the search list by default and doesn’t stop on a NODATA
response.
Some versions of nslookup have been modified by OS vendors to use /etc/hosts
for address lookups.
nslookup doesn’t display the entire response by default.
> On 20 Aug 2018, at 12:28 pm, Lee wrote:
>
> On 8/19
On 8/19/18, Doug Barton wrote:
> On 08/19/2018 12:11 PM, Lee wrote:
>> On 8/18/18, Doug Barton wrote:
>
>>> nslookup uses the local resolver stub. That's fine, if that's what you
>>> want/need to test. If you want to test specific servers, or what is
>>> visible from the Internet, etc. dig is the
On 08/19/2018 12:11 PM, Lee wrote:
On 8/18/18, Doug Barton wrote:
nslookup uses the local resolver stub. That's fine, if that's what you
want/need to test. If you want to test specific servers, or what is
visible from the Internet, etc. dig is the right tool, as the answers
you get from nsloo
On 8/18/18, Doug Barton wrote:
> On 08/18/2018 04:53 PM, Barry Margolin wrote:
>> In article ,
>> Grant Taylor wrote:
>>
>>> On 08/18/2018 07:25 AM, Bob McDonald wrote:
I don't think anyone hates nslookup (well maybe a few do ) I
suppose the immense dislike stems from the fact that it
On 08/18/2018 04:53 PM, Barry Margolin wrote:
In article ,
Grant Taylor wrote:
On 08/18/2018 07:25 AM, Bob McDonald wrote:
I don't think anyone hates nslookup (well maybe a few do ) I
suppose the immense dislike stems from the fact that it's the default
utility under Windows. Folks who use
In article ,
Grant Taylor wrote:
> On 08/18/2018 07:25 AM, Bob McDonald wrote:
> > I don't think anyone hates nslookup (well maybe a few do ) I
> > suppose the immense dislike stems from the fact that it's the default
> > utility under Windows. Folks who use dig as their default realize that
Extra complexity -- "man dig" yields 289 lines while "man nslookup"
yields only 160 lines.
Also, dig is not simply an extension of nslookup (which I long ago
abbreviated to nsl), but is significantly different, so it using it
involves the human analog of a cache miss.
On Sat, 18 Aug 2018 20:12:0
When I started using Linux almost 20 years ago, I think there was only
nslookup, and no dig. So by habit, I tend to use it unless the extra
power of dig outweighs its extra complexity. I don't remember what I
used on Windows back when I was regularly using both.
On Sat, 18 Aug 2018 11:42:20 -0600
On 08/18/2018 07:25 AM, Bob McDonald wrote:
I don't think anyone hates nslookup (well maybe a few do ) I
suppose the immense dislike stems from the fact that it's the default
utility under Windows. Folks who use dig as their default realize that
when used properly, dig provides much more functi
> I know that most of you hate nslookup but I have been using it since the
> 90's and it's my go-to utility. I get the same responses whether I use
> Dig or nslookup. If nslookup doesn't return what I am looking for, I do
> use Dig also.
I don't think anyone hates nslookup (well maybe a few do ) I
Seems ok here using: dig +trace srv _minecraft._tcp.skyblock.mc-game.us.
mc-game.us. 3600IN NS ns1.sleepyvalley.net.
mc-game.us. 3600IN NS sdns2.ovh.ca.
;; Received 113 bytes from 156.154.126.70#53(156.154.126.70) in 168 ms
_minecraft._tcp.skyb
Thanks all for your quick response. I didn't need a 2nd pair of eyes, I
needed a 2nd brain. I didn't think that I had to use the fully qualified
domain name and was just using the subdomain.domain.name for the
queries. What can I say, I'm old and going senile. Your responses showed
me the error
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2018-08-17 at 12:27 -0500, Thomas Strike wrote:
> I need a 2nd pair of eyes on this one.
Works for me.
dig _minecraft._tcp.skyblock.mc-game.us srv
;; ANSWER SECTION:
_minecraft._tcp.skyblock.mc-game.us. 300 IN SRV 0 5 25567 skyblock.mc-
ga
On Fri, Aug 17, 2018 at 1:28 PM Thomas Strike
wrote:
> I have created a SRV record for a new subdomain A record. I set nslookup
> to use my DNS server directly and when I query for the A record it
> returns it. When I set type=SRV and ask for the srv record nothing is
> returned.
>
> My SRV recor
I have created a SRV record for a new subdomain A record. I set nslookup
to use my DNS server directly and when I query for the A record it
returns it. When I set type=SRV and ask for the srv record nothing is
returned.
My SRV record: _minecraft._tcp.skyblock.mc-game.us. IN SRV 0 5
2556
19 matches
Mail list logo
