On 2012.11.15 10.14, Novosielski, Ryan wrote:
Failing to operate a private TLD correctly is causing internal
data leaking to the Internet, which could be a security risk but in
all cases is a burden on the root server system.
Not that I think that I'm doing this (and as I'd said, the only place
I use this is at home on a NAT'd network where there is no public DNS
at all), but what are some common ways to let this happen if you
happen to know?
a nat'd network is a prime example of exactly the sort of place this
kind of thing happens. what it usually boils down to is non public
namespace being used [be it invented tlds or rfc1918/5735/etc address
space] with no nameserver on the local network with those zones
configured as authoritative.
for example, someone decides it would be fun to have a play domain name
on their private network, but doesn't set up a nameserver [aside from
the simple caching nameserver built into their access device [dsl/cable
modem, router, whatever]]. naturally, hosts on the network are
constantly doing dns lookups which reference this domain name, and as
such, the access device tries to resolve said hostname, likely passing
the query on to some upstream resolver. regardless of it a forwarder is
used or traditional iterative queries are used by the access device, now
the query ends up getting shopped around in some capacity to various
nameservers, all on the public internet, to see if it can be resolved.
queries for dns data which will never exist on the public internet
should never make it beyond the borders of a private network. running
an authoritative nameserver with the proper zones loaded [and bind makes
this even easier with empty zones] is what prevents this from happening.
unfortunately, it is exceedingly common, as carsten points out, and in
some contexts has become bad enough - e.g. rfc1918 arpa space - that
separate nameservers have been set up to deal with the problem [rfc 6305].
-ben
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
