Re: [BIND-BUGS #18] Non-delegated master domains

[Bennett Todd <bet () newritz mordor net>]

(taken from bugtraq)

1999-05-10-09:21:17 Ian Carr-de Avelon:
> For me this is simply a problem relating to adding MX records with
> 192.168.xx.xx addresses to internal name servers. Some people may assume
> that if they rely on DNS data for their own domains, they are only relying
> on the intergrety of their own servers. With BIND 8 this appears not to be
> true. If somone can change the delegation of a domain, or make a new domain
> like EMIT. or 168.192.IN-ADDR.ARPA., bind 8 will accept the data pointed to
> via route servers etc. in place of local master files.
> [...]
> Replacing names with IPs in every context would be a pain. If nothing
> else, producing a fake 168.192.IN-ADDR.ARPA. would be a DOS attack
> against thousands of internal services as tcpds would refuse connections.

This is a great thing to know about when designing a firewall layout.

A lot of it can be well controlled against; in high-security settings, I
don't pass DNS data across the firewall at all, and the firewall itself
doesn't use DNS data for any purpose except making outbound connections;
everything else is IP addresses, and it keeps track of what packets come from
where by the interfaces they arrive on. And of course the external screening
router blocks all packets with src and dst addresses in the RFC 1918 ranges
(10/8, 172.16/12, and 192.168/16). I can see using e.g. 192.168.0/24 for
the crossover cable between the external screening router and the outside
interface of the firewall in a small shop that doesn't need a DMZ that can
contain hosts. As long as the firewall doesn't try ane make any use of DNS
data for these addresses I don't think I can see any potential problem there.

Can anybody see anything I'm missing in the above theorizing?

But for sure this is an important warning for people who want to stash
high-security servers on a 192.168 net, behind a firewall from a
light-security public net. If a a DNS server can see the internet, it can't be
trusted to remain authoritative for reverse lookups on 192.168/16 in the face
of a sufficiently clever and determined attack.

-Bennett