[nsd-users] Unsecured zone transfers and open resolvers

[Valentin Bud]

On 7/19/12 11:06 AM, Olaf Kolkman wrote:
>
> On Jul 18, 2012, at 10:16 PM, Valentin Bud wrote:
>
>> Hello,
>>
>> My question is not related to NSD in particular, but I have seen here 
>> on the list a lot of people that work for TLDs and other Registrars 
>> and Registry operators I thought it would be a good place to ask this 
>> question. It is about DNS though, not completely off topic :).
>>
>> I have encountered in my DNS studies a few name servers that let you 
>> transfer zones they are authoritative for. The name servers I am 
>> talking about are not under my control. I have noticed that in the 
>> majority of cases ns2.*, or whatever name the second NS has, lets you 
>> perform the zone transfer. This led me to the conclusion that the sys 
>> admins don't pay enough attention or don't really know or understand 
>> DNS technology. It is not my intention to offend any sys admin. I am 
>> just saying. Or maybe the people that set up those servers are not 
>> sys admins. Who knows.
>>
>> Do you consider the above as being a security vulnerability?
>
> There are different schools.
>
> One school shares your thoughts:
>
>> My thoughts on this. This isn’t necessarily bad if the only 
>> information provided is related to systems that are connected to the 
>> Internet and have valid hostnames, although it makes it that much 
>> easier for attackers to find potential targets. Almost all the time 
>> people use suggestive names like splunk, nagios, cpanel, 
>> switch-c2950, etc. That would give an attacker a good start. But on 
>> the other hand it can find those by himself by querying the name 
>> server for those names.
>>
>
> The other schools says that information in the DNS is essentially 
> public and while preventing *XFR will provide a bit of obscurity we 
> all know that security through obscurity doesn't provide real 
> security. (I am paraphrasing the school of thought).
I totally agree with you about security through obscurity. I tend to 
avoid it in anyway I can. And yes DNS information is essentially public.
>
>
>> In some cases, as I have seen, there are entries that have private 
>> addresses. I consider this as being quite bad because it reveals the 
>> private address space of the company's/institution's IT infrastructure.
>
> The second school of thought would probably say that if you put the 
> data in the DNS you do not mind disclosing the information. If you 
> want this sort of information to be hidden you set up 'internal-only' 
> infrastructure (with BIND you can use one server with two views, with 
> other implementations you set up your nameserver infrastructure 
> independently).
>
>>
>> What about open resolvers? I am not talking here about OpenDNS or 
>> Google, who monitor their infrastructure and maybe they even rate 
>> limit the queries per source IP address if too many come from one 
>> particular source. I am talking about servers that are not being 
>> monitored. I say this because if you monitor your servers and if you 
>> understand the DNS technology you can see that someone has AXFR-ed 
>> your zone or queried whatever.domain.com <http://whatever.domain.com> 
>> recursively using your name server and put an end to it.
>
> In the context of this conversation I believe that if an open, and 
> public facing, resolver has access to internal information (an 
> internal view) such would probably be a mistake. But if the open 
> resolver is configured to only see external facing data then I don't 
> see any reason for the type of monitoring you describe above.
>
> The type of monitoring that should always be taken place on open 
> recursive nameservers is monitoring for being used as DOS 
> amplification vector.

What do you mean by this? What kind of parameters should be monitored? 
Queries per second from a given IP address is my first guess.

Thank you for taking your time to respond. Cheers and Goodwill,
Valentin Bud

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20120720/5427d9bd/attachment.htm>