SRV record not working

[Doug Barton]

On 08/18/2018 04:53 PM, Barry Margolin wrote:
> In article <mailman.339.1534614089.803.bind-users at lists.isc.org>,
>   Grant Taylor <gtaylor at tnetconsulting.net> wrote:
> 
>> On 08/18/2018 07:25 AM, Bob McDonald wrote:
>>> I don't think anyone hates nslookup (well maybe a few do <grin>) 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 functionality than nslookup.
>>> For example, try using TSIG with nslookup or getting a NSID response.
>>> These are only a couple of examples. There's other reasons to change.
>>> The output from dig is much more comprehensive. And, yes, if you install
>>> the bind tools from ISC under Windows, dig works quite well.
>>
>> I've been told that nslookup will lie and provide incorrect information
>> in some situations.  I have no idea what situations that is.  I would
>> love to learn what they are.
>>
>> If you know of such an example, please enlighten me.
>>
>> As such, I tend to use nslookup on platforms without dig when or until I
>> have reason to not do so.
> 
> I don't think it "lies" much, but the output isn't as clear and
> unambiguous as dig's. When it reports errors, it can be difficult to
> tell specifically what the actual error was.
> 
> One example I can think of is that for some reason it expects the
> nameserver to be able to reverse-resolve its own IP. If it can't, it
> reports this as an error, and you might think that it's reporting an
> error about the name you're actually trying to look up.

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 nslookup cannot be guaranteed to be directly related to the 
question you asked.