Problems with named default configuration in 6-STABLE
dougb at FreeBSD.org
Tue Jul 17 21:01:55 UTC 2007
> On 07/17/07 18:14, Doug Barton wrote:
>> I'm sorry to say that you've provided a great deal of incorrect
>> information in this thread.
> sorry? really? I couldn't find one!
Yeah, that's part of the problem. Fortunately I'm here to help. :)
1. It's amusing, root servers B, C, F, G and K are operated by
ignoring (read: violating) RFC2870 explicit requirements.
2. Which in fact means, FreeBSD uses something which is a violation of
RFC2870 which is not guaranteed to work.
3. Using the root zone as type "stub" should work (even while ARM says
it's not DNS standard). But ARM says, it's not recommended for new
configurations (I have no idea why it does state that).
This is just plain bad advice, although at least you were honest
enough to say you didn't understand it.
4. The root zone MUST be of type hint.
5. hmm... the root servers should not allow public AXFR. As I've
verified using: dig @a.root-servers.net axfr .
First part is wrong, the second part ignores what's actually in
And my personal favorite,
6. If just 5 out of 13 root servers support AXFR, your bind will sit
for a while to find a root server responding to it's AXFR requests.
At best you pass opinions, rumors, and half-understood concepts off as
fact, and at worst you are truly dangerous. Sorry to be so blunt, but
I feel compelled to point out that what you're saying is wrong,
stupid, dangerous, or some combination thereof so that a perfectly
innocent user doesn't take you seriously.
>> Volker wrote:
>>> Remember, AXFR requires a TCP transfer and not every firewall will
>>> happily let it pass.
>> This is true, although since to the firewall an AXFR looks just like
>> any other stateful TCP connection out to the wide world, it's actually
>> more likely (percentage wise) that this will succeed than it is that
>> the DNS requests (using UDP) will. Obviously, for those that cannot
>> transfer the zone, the hints mechanism is still in the comments.
> I've seen setups (not mine but I also tend to suppress 53/tcp) to deny
> 53/tcp traffic.
How do you define "traffic" in this context. If you mean inbound port
53, it's irrelevant since named will use a random ephemeral port to
establish the outbound connection. If you mean systems that restrict
outbound port 53, that's just plain stupid, and in the immortal words
of Ron White, "You can't fix stupid."
> To see this as a common or uncommon setup is more
> likely a philosophical discussion.
And yet you are bringing it up in an operational context.
>>> I (partially) agree to the speedup effects you mentioned
>> I think you should read the paper that David posted,
>> http://www.imconf.net/imc-2004/papers/p15-malone.pdf before you
>> comment further.
> I never said, using hint or slave will have no impact on speed. Where
> did I write that? Read: "I agree to the speedup effects."
Apparently you still haven't read that paper, since you're still not
seeing the point.
>> It's also worth nothing that even if the only benefits were greater
>> reliability vs. a root DDoS attack (which is sadly no longer a
>> theoretical issue) and the substantial improvements to local NXDOMAIN
>> answers, it would be worth it. Add the benefits of at worst a wash
>> with overall root traffic for the root zone, and the extra benefits of
>> also having local copies of ARPA and IN-ADDR.ARPA (which are much
>> smaller, and usually more frequently queried than the root zone) and
>> it's a clear win.
> Ok, a DDoS attack against the root servers has happend a few times in
> the past but there has been no single moment in time when not a single
> root server could be reached. So yes, a DDoS attack is possible,
> slaving the root zone will make you still being able to resolve DNS
> addresses but this is a theoretic scenario to have none of 13 root DNS
> servers worldwide being unreachable.
You've chosen to highlight the least significant portion of this part
of my argument, and ignored all of the other benefits that I
mentioned. Even if a total root server blackout hasn't happened yet,
it is a vulnerability that can easily be avoided. I'm used to
operating in an environment where DNS is mission critical, and every
foreseeable vulnerability should be dealt with before it becomes a
>> I should add for the sake of completeness that not every DNS
>> professional has reached the same conclusions I have
> Sorry, but this reads as "nobody else has reached my wisdom".
Perhaps that was poorly phrased. What I meant was, there has been
considerable discussion about this topic over the last several years,
and two main viewpoints have arisen. One is that it's a good idea for
the reasons I stated, and two that it's a bad idea for the reason I
mentioned below. No one has said that doing this will be bad for the
root servers, and in fact 2 more roots have opened up AXFR over the
last 2 years.
I should probably also point out that I'm not speaking theoretically
here. I have pretty close ties with several of the root operators, and
I know most of the others. I've been involved in doing DNS for 13
years, and my last full time job was as General Manager of IANA. I'm
pretty sure that I know what I'm talking about.
> And it's
> comments like these which will get me away from using FreeBSD sometime
> in the future (while FreeBSD still being a great OS).
That's a personal decision that you will have to make for yourself.
>> , however the main
>> objection that is usually raised is not operational from the root
>> server operators, rather it's that DNS admins who are not paying
>> attention might miss a change that would prevent their local resolver
>> from slaving the zone at some time in the future. Given that the IP
>> addresses of the root servers hardly ever change, and given that we
>> have 5 servers to choose from (and we only need one good transfer to
>> make it work), and given that I (and as this thread points out,
>> others) actually do pay attention, I don't think this is going to be a
>> problem for us.
> The point is, when relying on something which is not guaranteed to
Um, this is just plain silly. You've drawn a flawed conclusion from a
series of flawed premises.
> ("SHOULD NOT reply to zone transfer requests" - RFC2870, 2.7) and
Apparently you still don't understand what "SHOULD NOT" means in this
context, even though someone else already tried to explain it to you.
> you're using this in a default OS configuration, you'll have trouble
> *if* the remaining 5 root DNS servers refuse to answer zone transfer
Yes, and IF you walk outside tomorrow and the laws of physics have
been suspended, you'll fly off the planet into space! Beware!
Seriously man, the root server operators move at what can best be
described as a glacial pace (not without good reason) and any change
to the AXFR practices would be announced far enough in advance to
allow for us to change things, and for the change to propagate to our
>>> but if just 5
>>> out of 13 root servers support AXFR, your bind will sit for a while to
>>> find a root server responding to it's AXFR requests.
>> I'm sorry, but that comment means that either you haven't read the new
>> named.conf, or you don't understand what you've read. Either way, you
>> should seriously consider whether or not it's a good idea for you to
>> continue offering DNS advice. The following:
> You're wrong. I've read named.conf and understood. In it, there're
> only 5 (of the total 13) root DNS servers configured as the root
> zone's master servers. Where have I been wrong? What did I don't
The fact that it's 5/13 is meaningless. There are 5 available masters,
named is going to be able to get to at least one of them without
"sitting for a while." In other words, the 8 that don't support AXFR
are totally meaningless in this context.
I've snipped the rest because I think I've hit the high points. I'm
going to try and resist the urge to respond if you choose to post
again, since I hope by now that I've made my point, and you know what
they say about trying to teach a pig to sing ....
This .signature sanitized for your protection
More information about the freebsd-stable