Re: [PLUG] DNS Packet Redirecting/Rewriting by ISPs

[gabriel rosenkoetter <gr@eclipsed.net>]

On Thu, Jun 12, 2003 at 03:07:27AM -0400, Michael F. Robbins wrote:
> I run an authoritative nameserver for my domains.  When I use standard
> DNS tools to query the nameserver *while ssh'd into the nameserver box*,
> everything looks fine.  However, when I use the same tools to query the
> nameserver from another computer remotely, passing through more than a
> dozen other hops, the packet comes back differently.

Could you show us precisely what commands you're using, please?

> Also supporting this theory is that when I query for other domains, like
> yahoo.com, on my nameserver, I should expect to get no response.

If your name server doesn't provide a response for yahoo.com when
you do something like this:

grappa:~% nslookup
Default Server:  localhost
Address:  127.0.0.1

> yahoo.com
Server:  localhost
Address:  127.0.0.1

Non-authoritative answer:
Name:    yahoo.com
Address:  66.218.71.198

then your nameserver is intensely broken. What software are you
using?

> Furthermore, the nameserver logs seem to support this.  None of my
> "yahoo.com" style queries are even sent to my server, while all of my
> successful (those that should be authoritative) queries appear to come
> from a Class C block of IPs that appears to represent a third party.

I'd have to see what you did to query your DNS to be sure.

> I did manage to find this document:
> "Optimizing ISP Networks and Services with DNS Redirection"
> http://www.nortelnetworks.com/products/library/collateral/intel_int/dns_wp.pdf
> Google PDF->HTML:
> http://216.239.39.100/search?q=cache:LUOHoIYtTegJ:www.nortelnetworks.com/products/library/collateral/intel_int/dns_wp.pdf+DNS+packet+redirected+ISP&hl=en&ie=UTF-8

That definitely sounds like what you're describing.

> Are my conclusions on the right track?  Is this a common practice in the
> ISP industry?  Of all the other hops between my workstation and the
> server, where might this rewriting be occuring?

Michael Toren's tcptraceroute would probably help you answer that.
(Trace to a host through port 22, then to the same host through 53.
See where the 53 dies. Oh... unless they're only redirecting UDP,
not TCP, traffic... in that case, UTSL.)

-- 
gabriel rosenkoetter
gr@eclipsed.net

Attachment: pgpwVIIZGDxwi.pgp
Description: PGP signature