Recursion is precisely what he was concerned about.  As you have
alluded, there are two roles for a DNS server, cacheing (which requires
recursion), and authoritataive.  An ISP does not need to publish the
addresses of a authoritative nameserver, those addresses are stored in
the distributed database and are therefore found naturally.  The only
reason for publishing an ISPs DNS server addresses to their customers is
for use as cacheing servers (often confusingly called resolvers). 
Whereas using another ISPs DNS cache servers may be technically possible
right now because of lax practices, I wouldn't want all my users to be
cut off by events beyond my control e.g. when said lax ISP engages a
half-decent DNS consultant.  Within DNS circles the practice is frowned
upon, and it might be held that it is actually criminal in several
juridsdictions.  My own belief is that running your own cacheing DNS
server is almost always the best solution, but then I am biased since
DNS is my specialism :-)
rgds
Marc TXK

Priscilla Oppenheimer wrote:
> 
> At 12:28 PM 2/18/02, Marc Thach Xuan Ky wrote:
> >Any decent ISP will refuse DNS recursion from any IP address that is not
> >within its own address space.
> 
> He wasn't asking about recursion. He was asking about the initial query
> from the end host. Although I could believe you that a service provider
> should make sure these queries only come from customers, my experience is
> that service providers don't do this. I can set my PC to use a variety of
> DNS servers around the Internet and it works.
> 
> I think it's because it's tricky to do, especially for small ISPs. Some
> ISPs might have only one DNS server. The same server that provides DNS
> services to Internet-access customers may also be the authority for various
> names managed by the ISP. The ISP may be doing Web hosting and be the
> authority for a bunch of names. In that case, it can't filter out DNS
> queries coming from the Internet.
> 
> For example, say your PC asks your local DNS server to resolve
> www.priscilla.com. Your server can't do it. It asks its upstream server,
> probably one of the root servers. The root server figures out that
> petiteisp.com owns www.priscilla.com and tells your server the IP address
> of the authoritative name server at petiteisp.com. Your server queries
> petiteisp.com which gives your server the IP address for www.priscilla.com.
> Your server finally responds to your PC.
> 
> Notice that the query to petiteisp.com came from some unexpected IP address
> that can't be anticipated in a filter. If petiteisp.com had a filter to
> allow queries only from its customers, the query from your server would
> have failed.
> 
> Did that make sense? ;-) How to bigger ISPs handle this? I suppose bigger
> ISPs have more than one DNS server, one for Internet access customers, and
> one that is the authority for names owned by the ISP.
> 
> Priscilla
> 
> >  This is fundamental to DNS security.
> >You need to rewrite the destination IP address.  Note that Cisco's NAT
> >is not suitable for this because of the DNS ALG.  The easiest thing to
> >do may be to provide an on-site cacheing DNS using the old ISPs DNS
> >addresses.  If you've got a lot of workstations and a decent bandwidth
> >to the Internet, you will probably find that running your own DNS cache
> >will be more satisfactory anyway.
> >rgds
> >Marc TXK
> >
> >
> >Godswill HO wrote:
> > >
> > > You can still use your former ISP's DNS records while using the new
ISP's
> > > bandwidth. It does not matter who owns the DNS server. Everybody have
> >access
> > > to it once they are in the internet. Except when they are specifically
> > > filtered.
> > >
> > > The only drawn back is that, Your new ISP have to forward the packet
in a
> > > round trip to the old ISP's network through the internet before they
are
> > > resolved and sent back to you machine, had it been you are using the
DNS
> of
> > > your new ISP, these request would stop there. Do not loose your sleep,
> > > because at the worst these delays are in milisseconds and not easily
> > > noticeable by the eye, more each machine have a cache so it does not
> >forward
> > > every request. Great if you have a Cache Engine to compliment the
> machine's
> > > cache.
> > >
> > > Whatever, you are kool and everything will be fine, switch to your new
> ISP
> > > and enjoy.
> > >
> > > Regards.
> > > Oletu
> > > ----- Original Message -----
> > > From: Michael Hair
> > > To:
> > > Sent: Sunday, February 17, 2002 8:07 PM
> > > Subject: DNS Request Redirection [7:35703]
> > >
> > > > I was wondering what is the best way to take care of the following:
> > > >
> > > > I have been using a private address space behind a Cisco 4500 router
> > > > connected up to our current ISP using NAT, now we want to move our
> > > > connection from our current ISP to a new ISP with better bandwidth.
My
> > > > problem is that we don't want to change all our client machines
TCP/IP
> > > > settings, which are all static, for some reason or another they were
> all
> > > > setup to use our ISP's DNS. Not my idea but that another problem. So
> how
> > > can
> > > > I setup our router to forward requests looking from our current ISP's
> DNS
> > > to
> > > > our new ISP's DNS without touching all the client machines.
> > > >
> > > > Would the best way be to use policy-base routing?
> > > >
> > > > Would a static route work?
> > > >
> > > > Could I use a static route under NAT?
> > > >
> > > > If someone could proved me a sample of how you could do this I would
be
> > > > greatful...
> > > >
> > > > Thanks
> > > > Michael
> > > _________________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.com address at http://mail.yahoo.com
> ________________________
> 
> Priscilla Oppenheimer
> http://www.priscilla.com




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=35805&t=35703
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to