dig +trace to find all the forwarders?
Josh Kuo
Mark Andrews
In message <n2t46e76f621004242012j9...@mail.gmail.com>, Jo
You need administrative access to see the overides to the normal resolution
process.
Mark
> Thanks in advance.
>
> -Josh
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Josh Kuo
process.You need administrative access to see the overides to the normal resolution
Mark Andrews
In message <u2q46e76f621004242101q7...@mail.gmail.com>, Jo
It's impossible.
>Or is this purely a designed limitation of dig?
Warren Kumari
On Apr 25, 2010, at 12:01 AM, Josh Kuo wrote:
> You need administrative access to see the overides to the normal
> resolution
> process.
>
>
> Just so I understand this completely, by administrative access you
> mean I need to be able to log in to each of the resolvers (not
> administrative access on my local workstation to do a 'sudo dig
> example.net a +trace'), correct?
>
> A follow up question to that... is it even possible to perform such
> a trace (revealing all resolvers) with the DNS protocol?
'tis not doable[0].
What is the root problem that you are trying to solve here? Is this
just to know because you want to, or are you trying to solve a
specific issue? In the very large majority of cases[1] your machine is
going to be querying whatever is configured in your resolv.conf (or
equivalent) and those nameservers will go do the resolution for you
(as opposed to multiple levels of forwarders).
[0]: I have horrid visions of someone responding back with some truly
horrendous kludge that involves looking up random strings and querying
heaps-o-servers to see if any of them had cached the answer or
something equally icky. Actually, you cloud see if the server that you
query is the one that actually touches the auth server, but this is
all ugly.
[1]: No hard data here -- does anyone have any sort of guestimate on
fraction of forwarded queries?
W
> Or is this purely a designed limitation of dig?
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
Josh Kuo
actually forwarding recursive queries to yet-another-server(s), and is
introducing slow name resolution and timeouts. In any case, I will
have to involve the ISP in troubleshooting and (hopefully) fixing the
problem. I was hoping there is some way to mimic "traceroute" with
"dig +trace", I didn't think so, and Mark confirmed it.
Warren Kumari
On Apr 26, 2010, at 3:10 AM, Josh Kuo wrote:
> What is happening is I suspect the DNS resolved IP given by my ISP is
> actually forwarding recursive queries to yet-another-server(s), and is
> introducing slow name resolution and timeouts.
Well, if you are just trying to figure out if the nameserver you are
asking is the one doing the resolution, this *might* help you out:
http://www.damia.com/whatismydns/
W
--
Militant Agnostic--I don't know and you don't either...
Lightner, Jeff
That link only shows the IP you came from and does a reverse lookup on
it. It doesn't seem to say anything about the nameserver.
http://www.damia.com/whatismydns/
W
Proud partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------
Warren Kumari
On Apr 26, 2010, at 10:41 AM, Lightner, Jeff wrote:
> ?
>
> That link only shows the IP you came from and does a reverse lookup on
> it. It doesn't seem to say anything about the nameserver.
Does it? Are you sure?
If so, I sent the wrong link -- the machine I was testing from is
also a nameserver, but I thought that was the right link...
W
--
Some people are like Slinkies......Not really good for anything but
they still bring a smile to your face when you push them down the
stairs.
Lightner, Jeff
desktop's browser.
Warren Kumari
On Apr 26, 2010, at 2:54 PM, Lightner, Jeff wrote:
> I'm sure that's all it displayed when I went to it from my Windows
> desktop's browser.
Uuuummm....
Are you maybe behind the same NAT that your recursive resolver is
behind and so your IP == your resolvers IP? Or is your Windows desktop
also your resolver?
Can you check by just going to www.damia.com (or whatismyip.com or
ipchicken.com or sshing into something and looking what your source is
or or or...)
W
--
After you'd known Christine for any length of time, you found yourself
fighting a desire to look into her ear to see if you could spot
daylight coming the other way.
-- (Terry Pratchett, Maskerade)t
Lightner, Jeff
Maybe I missed the point in the site. Is it to report the name server
your IP exist on (the one it returned the reverse lookup for) or is it
intended to run only from a name server? If the latter I don't see the
point of the site.
Kevin Darcy
process.You need administrative access to see the overides to the normal resolution
Just so I understand this completely, by administrative access you mean I need to be able to log in to each of the resolvers (not administrative access on my local workstation to do a 'sudo dig example.net a +trace'), correct?
However, if you send *recursive* queries, essentially giving some other resolver _carte_blanche_ to resolve the name any way it feels fit, then +trace isn't going to tell you diddly about whatever algorithm/configuration the other resolver might be using to get the information for you. It's basically a "black box" as far as you're concerned -- queries in, responses out. You don't know how or where it got the information.
Feel free to propose an equivalent layer to the DNS protocol as ICMP is to IP/TCP/UDP and get all of the DNS implementations out there to support the new protocol extension.
A follow up question to that... is it even possible to perform such a trace (revealing all resolvers) with the DNS protocol? Or is this purely a designed limitation of dig?
Then it might be possible to write a program analogous to "traceroute" for DNS.
- Kevin
Warren Kumari
On Apr 26, 2010, at 4:00 PM, Lightner, Jeff wrote:
> I'm certainly behind a NAT and the IP reported is the NATed IP.
And is the recursive resolver that you are using ALSO behind the same
NATed IP?!
>
> Maybe I missed the point in the site. Is it to report the name
> server
> your IP exist on (the one it returned the reverse lookup for) or is it
> intended to run only from a name server? If the latter I don't see
> the
> point of the site.
It is supposed to tell you the resolver that you are using -- actually
what it tells you is the address of the resolver that queried their
authoritative server. In the huge majority of the cases the resolver
you are using == the address of the resolver that touched them. The
original poster was asking if this was true for him (which is why I
suggested that he tries this).
I reconfigured my home server to use the resolvers provided my my ISP
(Verizon), and www.damia.com reports that my IP is: 71.114.43.183
(which it is!)
and that the resolver I am using is: 71.252.0.36.
Anyway, this has wandered offtopic.
W
>>>>> On Apr 25, 2010, at 12:01 AM, Josh Kuo wrote:
>>>>>
>>>>>
>>>>> You need administrative access to see the overides to the normal
>>>>> resolution
>>>>> process.
>>>>>
>>>>>
>>>>> Just so I understand this completely, by administrative access you
>>>>> mean I need to be able to log in to each of the resolvers (not
>>>>> administrative access on my local workstation to do a 'sudo dig
>>>>> example.net a +trace'), correct?
>>>>>
>>>>> A follow up question to that... is it even possible to perform
>>>>> such
>>>>> a trace (revealing all resolvers) with the DNS protocol?
>>>>>
>>>>>
>>>>> 'tis not doable[0].
>>>>>
>>>>> What is the root problem that you are trying to solve here? Is
>>>>> this
>>>>> just to know because you want to, or are you trying to solve a
>>>>> specific issue? In the very large majority of cases[1] your
>>>>> machine
>>>>> is going to be querying whatever is configured in your resolv.conf
>>>>> (or equivalent) and those nameservers will go do the resolution
>>>>> for
>>>>> you (as opposed to multiple levels of forwarders).
>>>>>
>>>>>
>>>>> [0]: I have horrid visions of someone responding back with some
>>>>> truly horrendous kludge that involves looking up random strings
>>>>> and
>>>>> querying heaps-o-servers to see if any of them had cached the
>>>>> answer or something equally icky. Actually, you cloud see if the
>>>>> server that you query is the one that actually touches the auth
>>>>> server, but this is all ugly.
>>>>>
>>>>> [1]: No hard data here -- does anyone have any sort of guestimate
>>>>> on fraction of forwarded queries?
>>>>>
>>>>> W
>>>>>
>>>>>
>>>>> Or is this purely a designed limitation of dig?
Barry Margolin
Warren Kumari <war...@kumari.net> wrote:
> On Apr 26, 2010, at 3:10 AM, Josh Kuo wrote:
>
> > What is happening is I suspect the DNS resolved IP given by my ISP is
> > actually forwarding recursive queries to yet-another-server(s), and is
> > introducing slow name resolution and timeouts.
>
> Well, if you are just trying to figure out if the nameserver you are
> asking is the one doing the resolution, this *might* help you out:
>
> http://www.damia.com/whatismydns/
>
Another way to do this is to look up the names whoami.ultradns.net or
whoami.akamai.net. The nameservers for these names return the
resolver's IP as the IP of the hostname.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Warren Kumari
On Apr 27, 2010, at 12:50 AM, Barry Margolin wrote:
> In article <mailman.1278.1272292...@lists.isc.org>,
> Warren Kumari <war...@kumari.net> wrote:
>
>> On Apr 26, 2010, at 3:10 AM, Josh Kuo wrote:
>>
>>> What is happening is I suspect the DNS resolved IP given by my ISP
>>> is
>>> actually forwarding recursive queries to yet-another-server(s),
>>> and is
>>> introducing slow name resolution and timeouts.
>>
>> Well, if you are just trying to figure out if the nameserver you are
>> asking is the one doing the resolution, this *might* help you out:
>>
>> http://www.damia.com/whatismydns/
>>
>
> Another way to do this is to look up the names whoami.ultradns.net or
> whoami.akamai.net. The nameservers for these names return the
> resolver's IP as the IP of the hostname.
Oh, hey, yeah, that's even better -- feel stupid for not suggesting
that originally....
W
>
> --
> Barry Margolin, bar...@alum.mit.edu
> Arlington, MA
> *** PLEASE don't copy me on replies, I'll read them in the group ***
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Hope is not a strategy.
-- Ben Treynor, Google