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?
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.
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.
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 recursively using your name server and put an end to it.
What are your thoughts on this matters?
Cheers and Goodwill,
Valentin Bud
I have encountered in my DNS studies a few name servers that let you
transfer zones they are authoritative for.
A number of TLD operators offer AXFR for their zones on purpose (e.g.
dig @xfr.lax.dns.icann.org . axfr
This led me to the conclusion that
the sys admins don't pay enough attention or don't really know or
understand DNS technology.
They do. Really. 
-JP
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).
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 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.
–Olaf
Here's a list of what you get when you restrain zone transfers:
- security through obscurity
- somewhat lighter load (on ram, cpu or network)
- a headache when some fool moves a server late on Friday
Add it up for yourself. Is the risk of running out of RAM bigger than the risk of someone reorganizing services and getting the ACLs wrong? Is security through obscurity something mildly desirable or something you want to avoid?
Arnt
Valentin,
I have encountered in my DNS studies a few name servers that let you
transfer zones they are authoritative for.
Do you consider the above as being a security vulnerability?
I do not. I find the various recommendations on "securing a DNS server"
to be largely unnecessary.
I leave all of my zones open for AXFR. I also sign my zones with NSEC
rather than NSEC3. I leave version.bind enabled on my hosts.
As far as I know none of this has caused any security problems.
Then again, I use Facebook and Google, and put my e-mail address on my
web page, so I'm not very careful about keeping information private.
YMMV.
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 can be by omission, or by decision. There is a difference between corporate domain and TLD or hosting company approaches.
Here's a list of what you get when you restrain zone transfers:
- security through obscurity
- somewhat lighter load (on ram, cpu or network)
- a headache when some fool moves a server late on Friday
the latter is mitigated by using TSIG keys for all transfers (highly recommended) or perhaps IP network ACLs (so if DNS slave address
changes "slightly" it would still work.)
Add it up for yourself. Is the risk of running out of RAM bigger than the risk of someone reorganizing services and getting the ACLs wrong? Is security through obscurity something mildly desirable or something you want to avoid?
obscurity is *not* security.
DNSSEC was designed with NXT (renamed to NSEC) RR type. Only much later NSEC3 type was added.
Root zone uses NSEC so they can as well allow AXFR.
By the way, even with NSEC3 one can still find out which RR types a name uses (cannot be obscured.)
Dmitry Kohmanyuk answers me:
Is security through obscurity something mildly desirable or something you want to avoid?
obscurity is *not* security.
Of course not. But many people seem to consider it something mildly desirable. See also "Security Through Warm Fuzzy Feeling" and the popular "Security Through Paying Oracle Large Sums".
Arnt
I have encountered in my DNS studies a few name servers that let you
transfer zones they are authoritative for.
A number of TLD operators offer AXFR for their zones on purpose (e.g.
dig @xfr.lax.dns.icann.org . axfr
I am aware of that. But that's just one, you said that there are a number of TLDs. Which are the other ones? I am curios. Why don't TLDs like .com or .net or .de offer AXFR for their zones. I guess that . offers it for improvement of the infrastructure as a whole. As FreeBSD's BIND states
"Slaving the following zones (., arpa) from the root name servers has some
significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
3. Greater resilience to any potential root server failure/DDoS"
And to answer my question about AXFR from .com TLD. I guess they don't do it because that would burden their servers and a lot of AXFRs would lead to DoS.
This led me to the conclusion that
the sys admins don't pay enough attention or don't really know or
understand DNS technology.
They do. Really.
I don't a strong argument against this so I agree with you for now. As I have said I don't mean to offend anyone. Although I have a real scenario in mind. A guy that works for a local University dealing with PR and other stuff is in charge of the DNS server for a specific department. The guy is smart but for sure it doesn't *really* understand DNS technology. And that's not offense, he knows that too. In my name space this kind of scenarios are easy to find.
Thank you very much for your thoughts JP.
Cheers and Goodwill,
Valentin Bud
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. 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
For a start: If you have a big zone (.com and .de are nastily big) and the zone transfer requests follow a Poisson distribution, zone transfers can really strain your RAM. That can be solved, but perhaps disallowing zone transfers is the simplest solution.
There are also a couple of other reasons. For example, some people will tell you that some countries have relevant privacy legislation, but I've never heard specifics. Consider it hearsay.
Arnt
I am aware of that. But that's just one, you said that there are a
number of TLDs. Which are the other ones? I am curios.
How about you try some of them? [You know how to get the root zone; the
rest is easy :-]
Why don't TLDs like .com or .net or .de offer AXFR for their zones.
A *gzipped* .COM zone file is currently around 2GB I hear. IMO .com
shouldn't offer AXFR ... 
-JP
Not to mention the commercial reasons. Like all the domain speculators and name droppers who’re currently hammering the registries for lucrative domains to typosquat. If public AXFR was available on .com/.de I’m sure such people would be initiating zone transfers every few seconds as well.
[This is off-topic for the NSD-users list and should move to the unbound-users list ]
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.
Yes, that is a good first order approximation. A significant amount of queries that are likely to amplify are good hints too (apex ANY +dnssec), but those are of the necessary but not sufficient category. And I actually do not have a comprehensive description of what needs happening.
Besides saying “Just don’t run an open resolver” http://tools.ietf.org/html/draft-ietf-dnsop-reflectors-are-evil-06 doesn’t say much about the topic.
Any other reader have hints?