DNS rebinding: prevention?

[Kevin Darcy]

I tend to agree. Trying to teach a firewall about all of the nuances of 
parsing DNS replies is basically reinventing the wheel. We already have 
a capable DNS-response-parser in the resolver, why not use it?

If a feature like this were implemented in BIND, though, I think the 
"safe" thing to do, from a security standpoint, is to give a REFUSED 
response if it were to otherwise give "forbidden" answers (address 
records that can be legally dropped, e.g. from the Additional Section in 
most circumstances, should simply be dropped). No way should BIND or any 
other nameserver implementation give *partial* RRsets in responses, or a 
NODATA response instead of an answerful response, just because the 
administrator declared that certain addresses were "bad". While this is 
"safe" from a security standpoint, it could easily break applications 
and/or subsystems, turning otherwise-successful lookups into 
irretrievably-failed ones. The documentation would need to clearly state 
USE THIS WITH EXTREME CAUTION.

In my personal opinion, this "rebinding" problem is really the fault of 
the crappy browser security model, not DNS, _per_se_, which has never 
presumed that any address record is going to persist for any arbitrary 
length of time. There's no "pinning" in DNS, never has been. So, any 
such feature by BIND or other DNS implementations just buys some time 
until the Security geniuses can redesign their deficient model.

- Kevin

Mordechai T. Abzug wrote:
> [resending from subscribed address]
>
> On Fri, Aug 03, 2007 at 09:50:28AM -0700, Chris Buxton wrote:
>
>   
>> named would have to check the address of each A or AAAA record
>> coming from the outside to see if it refers to an internal address.
>>     
>
> Yes.  And CNAMEs, too.  Maybe NS records, SRVs, MXs, and some other
> record types I'm not thinking of.  Which is OK -- bind already looks
> at the records at least a little bit, i.e. to cache them, to see if
> they match the query, etc.  IME, bind runs at low CPU utilization on
> modern hardware for 10K users: there's definitely room for more work
> to be done by bind.  And, of course, like any other feature, this
> should be able to be turned off for performance reasons or any other
> reason.  "Any feature that cannot be turned off is indistinguishable
> from a bug."
>
>   
>> This seems to be more a job for an application-level firewall that
>> can fully inspect the contents of DNS messages and filter based on
>> their contents.
>>     
>
> The DNS server is already parsing DNS replies and looking at them, to
> make sure that the query IDs match, that the answer is valid based on
> the query, to cache, etc.  The DNS server is the expert on DNS.  Why
> pass the buck to the firewall?
>
> Also, for large shops, where one hand doesn't know what the other is
> doing and there is a lot of specialization, I don't think you want the
> firewalls guys responsible for understanding DNS configurations.
> There are a lot of subtleties here -- offhand, delegations to the
> server, delegations from the server, and known-valid third-party DNS
> records that point to internal IPs or names.
>
> And quite aside from organizational issues, I personally work with
> both DNS products and firewall products.  I would trust a DNS server
> to do complicated things with DNS a lot more than I would trust a
> firewall to do complicated things with DNS.  The DNS servers
> (i.e. bind) have a lot more DNS-related knobs to turn, and clearly
> understand DNS better.
>
> In summary: yes, this can be worked around in a firewall, but it makes
> a lot of sense to provide a workaround in bind.
>
> - Morty
>
>
>
>
>