Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another DNS question...

On Thu, 24 Nov 2005 01:16:41 -0500
 Dan Shoop <email@hidden> wrote:
Many things will fail without _*name resolution*_. If you have bad DNS then names are resolved improperly and things break. If you either choose not to use names, not to use DNS namespaces, or to resolve names differently this is all perfectly acceptable too. It's not that you /must/ have DNS, it's just if you /do/ have DNS it /must/ be right.

DNS is just *a* way to resolve names.

You may find this hard to believe but DNS is a very recent protocol, and the Internet ran fine for eons without it. You might not remember it, but to me it's still a relative newcomer, like HTTP.

Uh, DNS was used on ARPAnet starting in 1983-4. I hardly
think that qualifies it as a newcomer, given that ARPAnet
was only 15 years old at the time. The "Internet" (ARPA,
NSFnet, BITnet, USEnet, take your pick) ran fine at the
time because there were several hundred, maybe a thousand
hosts on it, and it was pratical to just use centrally
distributed hosts files. Let's not build a straw man to
argue that the public commodity internet is *anything*
like the "Internet" was before the public came on board. You're not the only one here who used the "Internet" before 1994.
And regardless, NAT is a level 2/3 mapping and cares not one bit about DNS. It doesn't use it, need it or care about it. Not one bit. It's all IP addresses, no names are involved to protect the guilty. It says some IP address get's remapped to some other IP address, nothing more. NAPT says that some IP-address:port gets mapped to some other IP-address:port, still no names their either. NAT does not need DNS. Period.

Correct. You're the only person in this discussion who has
brought up this argument. You said most people shouldn't be running their own DNS, and I suggested that if the OP was NATing, he should run his own internally to resolve the private addresses, as that's *generally* easier than trying to get an ISP to resolve host.domain.com to two different IPs depending on where the request is coming from. You chose to read what I said as me asserting that NAT somehow requires DNS. Well, it doesn't and we both know that.

But you still haven't answered my biggest question: if blocking port 53 is just a bandaid for preventing DNS leakage of our private zones, what else should we be doing?

Properly configuring BIND in the first place. If you want to control who get's to resolve what how and viewed which way BIND is the place to do this, not a nasty hack at the border to make up for not doing the right thing to begin with.

Assuming the internal DNS server has a private IP and isn't multi-homed, there's no need for any border hacking OR extra BIND configuration. Can we agree that best practice for DNS resolution for a site using NAT/PAT and private IPs is to have public IPs resolved by an upstream ISP's DNS server and private IPs resolved by an internal, not routed, DNS server that will forward queries for hosts outside the private space to external DNS?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden

This email sent to email@hidden
References: 
 >Re: Another DNS question... (From: Dave Pooser <email@hidden>)
 >Re: Another DNS question... (From: Bret Alan <email@hidden>)
 >Re: Another DNS question... (From: Dan Shoop <email@hidden>)
 >Re: Another DNS question... (From: "Brendan O'Toole" <email@hidden>)
 >Re: Another DNS question... (From: Dan Shoop <email@hidden>)
 >Re: Another DNS question... (From: Bret Alan <email@hidden>)
 >Re: Another DNS question... (From: Dan Shoop <email@hidden>)
 >Re: Another DNS question... (From: Bret Alan <email@hidden>)
 >Re: Another DNS question... (From: Dan Shoop <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.