Re: dig +trace to find all the forwarders?

[Josh Kuo]

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. 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  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
>
>
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: one record to be redirected to a specific IP

[hugo hugoo]

What I want to do is redirect a site to a specific IP using DNS (this kind of 
request comes from the Justice).

This specific IP can be an internal website with a warning message for example.

 

So I need to could redirect www.abcd.com for example to a specific IP 1.2.3.4 
for example.

This redirection must not have any impact on other ur'ls like toto.www.abcd.com 
or "anything else".www.abcd.com

 

 

I  am also wondering if this is a problem to impact "anything 
else".www.abcd.com, if this kind of URL exists.

 

Thanks in advance for your help in this DNS world new to me.


 
> Date: Sun, 25 Apr 2010 13:36:33 -0700
> From: do...@dougbarton.us
> To: hugo...@hotmail.com
> CC: bind-us...@isc.org
> Subject: Re: one record to be redirected to a specific IP
> 
> On 04/25/10 13:19, hugo hugoo wrote:
> > Yes I need more help on this item.
> > Your answer seems to indicate thate there is no way to only redirect
> > www.abcd.com to IP 1.2.3.4
> 
> That's essentially correct.
> 
> > toto.www.abcd.com will either be redirected to the same IP (zone file
> > with * A 1.2.3.4)
> 
> It doesn't have to be the same IP, it could be a different one. You can
> even specify some specific host names with certain IP addresses, with or
> without a wild card for everything else. There are a lot of
> possibilities, but until you tell us EXACTLY what it is you want to
> accomplish, it's next to impossible to provide you useful help.
> 
> > So can we redirect only www.abcd.com without any
> > impact on toto.www.abcd.com?
> 
> No. Once you create a zone www.abcd.com it will have an impact on
> .www.abcd.com.
> 
> 
> Doug
> 
> -- 
> 
> ... and that's just a little bit of history repeating.
> -- Propellerheads
> 
> Improve the effectiveness of your Internet presence with
> a domain name makeover! http://SupersetSolutions.com/
> 
  
_
Nouveau Windows 7 : Simplifiez votre quotidien
http://windows.microsoft.com/fr-BE/windows7/products/home?os=win7___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: one record to be redirected to a specific IP

[Sten Carlsen]

I wonder if the following could be done:

- make the zone for www.abcd.com, which would also redirect the
"anything else" part.
- delegate the "anything else" back to its original owner.

like:

www.abcd.com.   soa 
@ IN   A1.2.3.4
*   NS

I am not sure this could work? I am not sure how this redelegation would
be seen by the original servers of the zone?

On 26/04/10 10:05, hugo hugoo wrote:
> What I want to do is redirect a site to a specific IP using DNS (this
> kind of request comes from the Justice).
> This specific IP can be an internal website with a warning message for
> example.
>  
> So I need to could redirect www.abcd.com  for
> example to a specific IP 1.2.3.4 for example.
> This redirection must not have any impact on other ur'ls like
> toto.www.abcd.com or "anything else".www.abcd.com
>  
>  
> I  am also wondering if this is a problem to impact "anything
> else".www.abcd.com, if this kind of URL exists.
>  
> Thanks in advance for your help in this DNS world new to me.
>
>  
> > Date: Sun, 25 Apr 2010 13:36:33 -0700
> > From: do...@dougbarton.us
> > To: hugo...@hotmail.com
> > CC: bind-us...@isc.org
> > Subject: Re: one record to be redirected to a specific IP
> >
> > On 04/25/10 13:19, hugo hugoo wrote:
> > > Yes I need more help on this item.
> > > Your answer seems to indicate thate there is no way to only redirect
> > > www.abcd.com to IP 1.2.3.4
> >
> > That's essentially correct.
> >
> > > toto.www.abcd.com will either be redirected to the same IP (zone file
> > > with * A 1.2.3.4)
> >
> > It doesn't have to be the same IP, it could be a different one. You can
> > even specify some specific host names with certain IP addresses, with or
> > without a wild card for everything else. There are a lot of
> > possibilities, but until you tell us EXACTLY what it is you want to
> > accomplish, it's next to impossible to provide you useful help.
> >
> > > So can we redirect only www.abcd.com without any
> > > impact on toto.www.abcd.com?
> >
> > No. Once you create a zone www.abcd.com it will have an impact on
> > .www.abcd.com.
> >
> >
> > Doug
> >
> > --
> >
> > ... and that's just a little bit of history repeating.
> > -- Propellerheads
> >
> > Improve the effectiveness of your Internet presence with
> > a domain name makeover! http://SupersetSolutions.com/
> >
>
> 
> Important ! Le domaine @hotmail.BE est désormais disponible en
> Belgique. Cliquez ici et créez votre adresse
> 
>
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

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

Re: one record to be redirected to a specific IP

[Torsten]

Am Mon, 26 Apr 2010 11:30:26 +0200
schrieb Sten Carlsen :

> I wonder if the following could be done:
> 
> - make the zone for www.abcd.com, which would also redirect the
> "anything else" part.
> - delegate the "anything else" back to its original owner.
> 
> like:
> 
> www.abcd.com.   soa 
> @ IN   A1.2.3.4
> *   NS
> 
> I am not sure this could work? I am not sure how this redelegation
> would be seen by the original servers of the zone?
> 


Bind would refuse to load that zone since a wildcard can't have NS
records.


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

Re: one record to be redirected to a specific IP

[Phil Mayers]

On 26/04/10 12:44, Torsten wrote:

Am Mon, 26 Apr 2010 11:30:26 +0200
schrieb Sten Carlsen:


I wonder if the following could be done:

- make the zone for www.abcd.com, which would also redirect the
"anything else" part.
- delegate the "anything else" back to its original owner.

like:

www.abcd.com.   soa 
@ IN   A1.2.3.4
*   NS

I am not sure this could work? I am not sure how this redelegation
would be seen by the original servers of the zone?




Bind would refuse to load that zone since a wildcard can't have NS
records.


As I've mentioned, "unbound" can do this. If the OP want's to stick with 
bind, but can tolerate it, he could do something like:


zone "abcd.com" {
  type forward;
  forward only;
  forwarders { 127.0.0.1 port 5300; };
};

...and then run a copy of unbound locally with unbound.conf:

port: 5300
local-data: "www.abcd.com 600 IN A "

...plus other required config of course.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dig +trace to find all the forwarders?

[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



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

RE: dig +trace to find all the forwarders?

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

-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  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.
--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Caching DNS server (bind9.4.2) CPU usage is so so so high.

[Dave Sparro]

On 4/25/2010 10:23 PM, Trần Trọng Tấn wrote:



Hi, I have a caching-only dns server which get ~3k queries per second.
Here is specs:

|Xeon  dual-core2,8GHz  4GB  of RAM

Centos  5x  32bit(kernel2.6.18-164.15.1.el5PAE)

bind9.4.2
|

rndc status: recursive clients: 666/4900/5000

Bind always uses 100% on one core on single-thread config. After I
recompiled it to multi-thread, it uses nearly 200% on two core :( No
iowait, only sys and user. I searched around but didn't see any info
about how bind use CPU. Why does it become bottleneck?



Upgrade.  BIND 9.5 has some pretty big changes to the way the cache is 
handled.  You may be able to make some adjustments to the 'cache 
cleaning interval' in your current configuration, but that won't really 
fix the problem I suspect you are seeing.


**NOTE**
the BIND 9.5.x branch is actually pretty old, I'd suggest skipping it 
and going right to one of newer Extended Support Versions (9.6 or 9.7).

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

Re: dig +trace to find all the forwarders?

[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



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




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

RE: dig +trace to find all the forwarders?

[Lightner, Jeff]

I'm sure that's all it displayed when I went to it from my Windows
desktop's browser.

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



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

Re: dig +trace to find all the forwarders?

[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




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

RE: dig +trace to find all the forwarders?

[Lightner, Jeff]

I'm certainly behind a NAT and the IP reported is the 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.

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

Re: dig +trace to find all the forwarders?

[Kevin Darcy]

On 4/25/2010 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?
+trace only shows the workings of the standard iterative-resolution 
algorithm, as if your local resolver, starting with only hardcoded 
information about the root zone, were doing all of the work necessary to 
obtain the requested information using *non-recursive* queries to trace 
the delegation chain(s).


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.


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?


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.


Then it might be possible to write a program analogous to "traceroute" 
for DNS.



- Kevin


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

Re: dig +trace to find all the forwarders?

[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




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

Re: dig +trace to find all the forwarders?

[Barry Margolin]

In article ,
 Warren Kumari  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 ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users