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
-----Original Message-----
From: Warren Kumari [mailto:war...@kumari.net]
Sent: Monday, April 26, 2010 3:14 PM
To: Lightner, Jeff
Cc: Josh Kuo; bind-us...@isc.org
Subject: Re: dig +trace to find all the forwarders?
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
-----Original Message-----
From: Warren Kumari [mailto:war...@kumari.net]
Sent: Monday, April 26, 2010 2:20 PM
To: Lightner, Jeff
Cc: Josh Kuo; bind-us...@isc.org
Subject: Re: dig +trace to find all the forwarders?
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
-----Original Message-----
From: bind-users-bounces+jlightner=water....@lists.isc.org
[mailto:bind-users-bounces+jlightner=water....@lists.isc.org] On
Behalf
Of Warren Kumari
Sent: Monday, April 26, 2010 10:29 AM
To: Josh Kuo
Cc: bind-us...@isc.org
Subject: Re: dig +trace to find all the forwarders?
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
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.
On Sunday, April 25, 2010, Warren Kumari <war...@kumari.net> wrote:
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-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Militant Agnostic--I don't know and you don't either...
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
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.
----------------------------------
--
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.
--
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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
