Re: SRV record not working

2018-08-18 Thread Paul Kosinski
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:01 +0200
Reindl Harald  wrote:

> 
> 
> Am 18.08.2018 um 20:02 schrieb Paul Kosinski:
> > 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. 
> 
> which extra complexity?
> 
> because you have to add an @ when you want to use a non-default
> nameserver and that you need "dig -X" for a reverse-lookup?
> 
> you can use dig as nslookup, it's not required that you add a record
> type - just "dig whatever" which is in that case even shorter
> 
> > On Sat, 18 Aug 2018 11:42:20 -0600
> > Grant Taylor via bind-users  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 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
> 
> 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: SRV record not working

2018-08-18 Thread Doug Barton

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 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.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Local Slave copy of root zone

2018-08-18 Thread Doug Barton

On 2018-08-15 10:43, Tony Finch wrote:

Doug Barton  wrote:


Slaving the root and ARPA zones is a small benefit to performance for 
a busy

resolver, [...]


This technique is particularly useful for folks in bad/expensive 
network
conditions. While the current anycast networks of root servers is much 
better

than it was "in the old days," the more data you have locally the more
resilient you are to DDOS against those targets.


I should probably have said that it isn't just RFC 8198:

* synth-from-dnssec (RFC 8198) synthesizes negative answers, so in most
  cases you don't need to talk to the authorities to find out that the
  answer is no; this is on by default


If you're slaving the zone on the resolver, that resolver is 
authoritative for the zone, so it doesn't need to query another server 
to prove that the answer is no.



* prefetch (https://tools.ietf.org/html/draft-wkumari-dnsop-hammer [1])
  means your users won't suffer the latency of talking to the 
authorities

  when a popular name expires from the cache; this is on by default


If you're slaving the zone, there is no cache to expire.


* stale-answer-enable / max-stale-ttl
(https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale)
  means you can still function for a while if you can't reach the 
authorities


This is a terrible idea, so not having it is a good thing.  :)

These are all general-purpose features, not at all specific to the 
root.


I think a local root was clearly a good idea before DNSSEC; since 2010 
I

have been less comfortable with it.


How, specifically, is DNSSEC affected by the validating resolver having 
a local copy of the root zone?


Doug
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: SRV record not working

2018-08-18 Thread Barry Margolin
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 
> > 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.

-- 
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


re: SRV record not working

2018-08-18 Thread Bob McDonald
> 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 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.

Just my $.02

Bob
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: SRV record not working

2018-08-18 Thread Grant Taylor via bind-users

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 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.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: SRV record not working

2018-08-18 Thread Paul Kosinski
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
Grant Taylor via bind-users  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 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.
> 
> 
> 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users