Re: DNS Forwarders to ISP Is it necessary?

> Sure, but I was wondering if there was a report of direct
> cache pollution -- but now that I think about it such a report
> would require close questioning (cross examination) to make
> sure those reporting were aware of the above issue.

But there is indeed such report. The most recent update to the recent cache
pollution imbroglio provided a direct link between a compromise upstream
(ISP) DNS server and cache poinsoning on the servers forwarding to them. I
think you will the report on sans web site.


> Yes, but I would only allow this (Port 53) for the designated
> CACHING ONLY DNS server (which really should be a
> sacrificial host -- it corrupted, just re-install or restore from
> backup without consideration for any 'data' on the server.)

I'd agree here - as long as that "caching only" server is under your
control. So, then we arrive at the same result: if you have to forward,
forward to a DNS server that YOU control and secure, NOT your ISP servers.
Just because your ISP is big does not mean that they follow good security
practice, or run secure DNS servers. We just recently heard about an ISP
that was wildcarding the whole .com zone just because they are too lazy (or
dumb or both) to learn how to create zones.

One of the original primary reasons for forwarding was the need to conserve
bandwidth. Now that 3-meg DSL/cable home networks are common place, such
needs are moribund.

--

Sincerely,
Dèjì Akómöláfé, MCSE+M MCSA+M MCP+I
Microsoft MVP - Directory Services
www.readymaids.com - we know IT
www.akomolafe.com
Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon
"Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message
news:ef45KrWQFHA.2736@xxxxxxxxxxxxxxxxxxxxxxx
> "Deji Akomolafe" <noemail@xxxxxxxxxxxxxxxx> wrote in message
> news:uCmTVSVQFHA.3416@xxxxxxxxxxxxxxxxxxxxxxx
>> > Isn't there a current report of cache pollution even with that check
> box?
>>
>> THAT is the crux of the matter. And that is why you DON'T want to
>> forward.
>> When you forward, you are telling your DNS server to TRUST the data
> supplied
>> by the DNS server you are forwarding to. You forward request to a
>> compromised server, the compromised server feeds garbages back to your
>> DNS
>> server. Your DNS server has no other option but to trust and accept that
>> garbage. That is how poisoning happens on a Windows DNS server that has
> that
>> check box enabled.
>
> Sure, but I was wondering if there was a report of direct
> cache pollution -- but now that I think about it such a report
> would require close questioning (cross examination) to make
> sure those reporting were aware of the above issue.
>
>> IF your DNS server is fetching the data directly on its own (using the
> roots
>> servers instead of forwarding to an ISP's server), and IF your DNS server
> is
>> protected against cache poisoning, the Root Servers would have to be
>> compromised first for you to experience the problem described above.
>
> Correct again. (Unless there is a bug which I am beginning
> to doubt.)
>
>> I personally think that it will be easier to compromise an ISP DNS server
>> than it'd be to compromise the root servers. Besides, if the root servers
>> were compromised, forwarding to an ISP server will not protect you
>> anyway.
>
> My first thought was that easier would be wrong, but then
> the Root survers don't keep a resolution cache, just the fixed
> glue records of the top level domains so there is less opportunity
> to attack them.
>
> As you say, using the ISP as intermediary would be no
> protection anyway -- the root gets hit, ISP gets hit, and
> for that matter EVERYONE in the world (practically)
> gets hit.
>
>> WRT leaving your DNS server INSIDE your network, why would you need to do
>> otherwise? Or why would keeping it inside necessitate forwarding? Your
>> DNS
>> servers stay inside behind your firewall.
>
> If you are referring to something that I wrote about "internal
> DNS" that was NOT my point or definition of "internal DNS
> server".
>
> I was referring to the internal DNS servers that run your own
> zones and are likely running on DCs in a Windows Domain.
>
> I do not want these servers on the Internet (except maybe to
> MS Windows Update etc.) at all, and certainly do not want
> them visiting random DNS servers like the ones at some
> place like "EvilHackersWillGetYou.ru"
>
>> In order for them to forward to
>> your ISP, they would need a way to get to the ISP's DNS servers, right?
> That
>> "way" is port 53. This is the same port they would use anyway IF you stop
>> forwarding. I guess I'm not understanding the point here.
>
> Yes, but I would only allow this (Port 53) for the designated
> CACHING ONLY DNS server (which really should be a
> sacrificial host -- it corrupted, just re-install or restore from
> backup without consideration for any 'data' on the server.)
>
>
>
>
>
>


.

Relevant Pages

  • Re: Cannot get access to router on SBS server
    ... point the DNS server setting to the IP of the SBS ... calling CNetCommit::ValidateFulltimeConnectionProperties. ... Call to Reading web publishing selection returned ok. ...
    (microsoft.public.windows.server.sbs)
  • Re: Herb Martin...Global Catalog SRV record missing!
    ... Error: Root hints list has invalid root hint server: ... DNS server: 128.63.2.53 ... PTR record query for the ...
    (microsoft.public.windows.server.dns)
  • RE: Exchange event ID 104
    ... server was configured and VP's who wanted to choose which SMTP they sent from. ... ISP, the cause could be the internet connection of DNS server at ISP is not ... PLEASE NOTE the newsgroup SECURE CODE and PASSWORD were ...
    (microsoft.public.windows.server.sbs)
  • [UNIX] Hardening the BIND DNS Server
    ... Hardening the BIND DNS Server ... Your Domain Name Service is the road sign to your systems on the Internet. ...
    (Securiteam)
  • Re: NTDS Inbound neighbos removal
    ... There is no primary WINS server defined for this adapter. ... There is no secondary WINS server defined for this adapter. ... PASS - All the DNS entries for DC are registered on DNS server ... Upper Component: NWLink SPX/SPXII Protocol ...
    (microsoft.public.windows.server.active_directory)
Loading