dig +trace question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

dig +trace question

Ronald F. Guilmette
I just recently "upgraded" my old FreeBSD system to the latest, 12.0
release.  Now, something that used to work doesn't seem to work anymore,
specifically "dig +trace" seems to no longer function at all.

Example:

================================================================
% dig +trace -x 195.154.23.103

; <<>> DiG 9.12.4-P1 <<>> +trace -x 195.154.23.103
;; global options: +cmd
;; Received 17 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms


================================================================

That's all I get.  No more outout.

It's probably my fault... somehow.  I've revised my firewall rules
and also, I'm now using local-unbound on the machine in qquestion,
whereas before I was just using 8.8.8.8.

I just need to ask:  How can I debug this?  I need to get back to having
this work.

Also, on a different machine that I have also recently upgraded to
FreeBSD 12.0 I am not getting the following strange and unexpected
error when running dig, regadless of options or arguments:

   Shared object "libdl.so.1" not found, required by "dig"

So, I need to ask also:  What's the proper for this separate and
different error?

(Note:  On both machines, the particular package I have installed that
is providing me with the "dig" command is: bind-tools-9.12.4P1.)
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dig +trace question

Matt Rowley
Hi Ronald,
You usually need to reinstall packages and ports after you do a major version upgrade to FreeBSD.

pkg update && pkg upgrade

You should see bind-tools in the list. Version might stay the same but you’ll be getting a different version, compiled against FreeBSD 12.

cheers,
—Matt



> On Jun 20, 2019, at 5:33 PM, Ronald F. Guilmette <[hidden email]> wrote:
>
> I just recently "upgraded" my old FreeBSD system to the latest, 12.0
> release.  Now, something that used to work doesn't seem to work anymore,
> specifically "dig +trace" seems to no longer function at all.
>
> Example:
>
> ================================================================
> % dig +trace -x 195.154.23.103
>
> ; <<>> DiG 9.12.4-P1 <<>> +trace -x 195.154.23.103
> ;; global options: +cmd
> ;; Received 17 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
>
>
> ================================================================
>
> That's all I get.  No more outout.
>
> It's probably my fault... somehow.  I've revised my firewall rules
> and also, I'm now using local-unbound on the machine in qquestion,
> whereas before I was just using 8.8.8.8.
>
> I just need to ask:  How can I debug this?  I need to get back to having
> this work.
>
> Also, on a different machine that I have also recently upgraded to
> FreeBSD 12.0 I am not getting the following strange and unexpected
> error when running dig, regadless of options or arguments:
>
>   Shared object "libdl.so.1" not found, required by "dig"
>
> So, I need to ask also:  What's the proper for this separate and
> different error?
>
> (Note:  On both machines, the particular package I have installed that
> is providing me with the "dig" command is: bind-tools-9.12.4P1.)
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dig +trace question

Ronald F. Guilmette
In message <[hidden email]>, you wrote:

>Hi Ronald,
>You usually need to reinstall packages and ports after you do a major
>version upgrade to FreeBSD.

I guess that I did not make myself clear.  Everything on this system is
freshly installed, from scratch.

I have the FreeBSD package "bind-tools-9.12.4P1" installed.... the latest,
undoubtedly compiled against FreeBSD 12.0.

Anyway, it really does appear now that this problem *is* a regression in
dig, and that it's not just me.

I tried my dig with both +trace -and -x also on *two* different Ubuntu
system I have here.

On Ubuntu 16.04 LTS it works as expected.

On Ubuntu 18.04 LTS it fails as I have reported.

It looks to me like somebody broke dig.

Where do I file the formal bugreport?


Regards,
rfg
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dig +trace question

Nico CARTRON
Are you sure it's not your setup?
I have plenty of dig running on FreeBSD (with bind-utils 9.14) and also Debian and they work just fine.

--
Nico

> On 21 Jun 2019, at 09:14, Ronald F. Guilmette <[hidden email]> wrote:
>
> In message <[hidden email]>, you wrote:
>
>> Hi Ronald,
>> You usually need to reinstall packages and ports after you do a major
>> version upgrade to FreeBSD.
>
> I guess that I did not make myself clear.  Everything on this system is
> freshly installed, from scratch.
>
> I have the FreeBSD package "bind-tools-9.12.4P1" installed.... the latest,
> undoubtedly compiled against FreeBSD 12.0.
>
> Anyway, it really does appear now that this problem *is* a regression in
> dig, and that it's not just me.
>
> I tried my dig with both +trace -and -x also on *two* different Ubuntu
> system I have here.
>
> On Ubuntu 16.04 LTS it works as expected.
>
> On Ubuntu 18.04 LTS it fails as I have reported.
>
> It looks to me like somebody broke dig.
>
> Where do I file the formal bugreport?
>
>
> Regards,
> rfg
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users

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

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dig +trace question

Ronald F. Guilmette
In message <[hidden email]>,
Nico Cartron <[hidden email]> wrote:

>Are you sure it's not your setup?
>I have plenty of dig running on FreeBSD (with bind-utils 9.14) and also
>Debian and they work just fine.

You know what?  I think we may both be right.

Checking now, I think I see the problem.  There is some sort of a problematic
interaction happening -only- between "dig +trace" and either unbound or
local-unbound.

On my old Ubuntu 16.04 system, /etc/resolv.conf contains only:

     nameserver 8.8.8.8
     nameserver 8.8.4.4

(Those are the public Google name servers, of course.)

On that system "dig +trace" works, no problem.

On my two newer systems, Ubuntu 18.04 and FreeBSD 12.0 instead of me relying
on Google's public name servers, the /etc/resolv.conf  files on these two
newer systems both contain only:

    nameserver 127.0.0.1

On one, I'm running a local instance of unbound, and on the other I am
running a local instance of local-unbound.  On these two systems "dig +trace"
DOES NOT just work.  In fact it fails essentally immediately in both cases,
regardless of whether you're trying to do the +trace on a normal sort of FQDN
-or- for some .in-addr.arpa name, where you give the argument as "-x A.B.C.D".

HOWEVER I found a trivial way to make the +trace work even on these systems.
Apparently, you just have to goose it a bit, and just get it sort-of kick
started.  And you can do that just by simply giving it a clear idea of
where it should begin the whole process.  You can do that by simply appending
"@a.root-servers.net" to the end of the command line.  If you do that, then
the trace works as expexcted.  (NOTE:  It is not necessary to use the "A"
root server in particular.  Any one of the root servers seems to do just
as well.)

So now, this all begs the Rodney King question:  Can't we all just get along?

What is it about unbound/local-unbound that makes it not plug and play well
with dig +trace?  What is it that Google's public name servers are doing
that a local running instance of unbound and/or local-unbound isn't doing?


Regards,
rfg
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dig +trace question

Anand Buddhdev
On 21/06/2019 04:55, Ronald F. Guilmette wrote:

> What is it about unbound/local-unbound that makes it not plug and play well
> with dig +trace?  What is it that Google's public name servers are doing
> that a local running instance of unbound and/or local-unbound isn't doing?

This is a very subtle bug.

Unbound does NOT allow non-recursive queries by default. If you want to
allow non-recursive queries, you have to configure this with the
"allow_snoop" ACL.

Now, dig with +trace used to send all its queries without setting the RD
flag. Most recursive resolvers don't mind, and will still answer.
However, unbound doesn't like this. When you run dig with +trace, and
you don't provide it a root name server to start with, then it asks the
local resolver for ./NS, without the RD flag, and unbound won't answer.

Funnily enough, this issue was noticed by Tore Anderson, who correctly
said that dig, even with +trace, should do its initial ./NS query WITH
the RD flag set. He reported it to ISC in issue #1028, and it has been
fixed with BIND version 9.14.3. So if you are able to try this newest
version with your setup, I hypothesise that it will work.

Regards,
Anand Buddhdev
RIPE NCC
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dig +trace question

Ronald F. Guilmette
In message <[hidden email]>,
Anand Buddhdev <[hidden email]> wrote:

>On 21/06/2019 04:55, Ronald F. Guilmette wrote:
>
>> What is it about unbound/local-unbound that makes it not plug and play well
>> with dig +trace?  What is it that Google's public name servers are doing
>> that a local running instance of unbound and/or local-unbound isn't doing?
>
>This is a very subtle bug.
>
>Unbound does NOT allow non-recursive queries by default. If you want to
>allow non-recursive queries, you have to configure this with the
>"allow_snoop" ACL.
>
>Now, dig with +trace used to send all its queries without setting the RD
>flag. Most recursive resolvers don't mind, and will still answer.
>However, unbound doesn't like this. When you run dig with +trace, and
>you don't provide it a root name server to start with, then it asks the
>local resolver for ./NS, without the RD flag, and unbound won't answer.
>
>Funnily enough, this issue was noticed by Tore Anderson, who correctly
>said that dig, even with +trace, should do its initial ./NS query WITH
>the RD flag set. He reported it to ISC in issue #1028, and it has been
>fixed with BIND version 9.14.3. So if you are able to try this newest
>version with your setup, I hypothesise that it will work.

Thanks for all of the detailed info!  It most probably would have taken
me a long long time (and a lot of work) to figure all this out on my
own.

I'll switch to using the 9.14.3 or 9.15.0 dig command as soon as possible.
Until then I have a nice temprary workaround, which is to just append
@a.root-servers.net to my dig +trace commands.


Regards,
rfg


P.S.  Stylistically, I like the dig +trace command output MUCH better
than the equivalent "drill -T" output.  Plus I've just been informed
that "drill -T" doesn't even actually work in conjunction with the -x
option. :-(
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dig +trace question

Anand Buddhdev
On 21/06/2019 22:01, Ronald F. Guilmette wrote:

Hi Ronald,

> I'll switch to using the 9.14.3 or 9.15.0 dig command as soon as possible.
> Until then I have a nice temprary workaround, which is to just append
> @a.root-servers.net to my dig +trace commands.

Just one note. 9.15.0 has the same problem. If you want to use the
development version, then you'll need the recently-released 9.15.1,
where this issue has also been fixed.

Regards,
Anand
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dig +trace question

Ronald F. Guilmette
In message <[hidden email]>,
Anand Buddhdev <[hidden email]> wrote:

>On 21/06/2019 22:01, Ronald F. Guilmette wrote:
>> I'll switch to using the 9.14.3 or 9.15.0 dig command as soon as possible.
>> Until then I have a nice temprary workaround, which is to just append
>> @a.root-servers.net to my dig +trace commands.
>
>Just one note. 9.15.0 has the same problem. If you want to use the
>development version, then you'll need the recently-released 9.15.1,
>where this issue has also been fixed.

ACK.  Thank you yet again for the very specific and helpful information.


Regards,
rfg

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

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users