Date: Tue, 17 Jul 2007 14:01:52 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Volker <volker@vwsoft.com> Cc: freebsd-stable@freebsd.org Subject: Re: Problems with named default configuration in 6-STABLE Message-ID: <469D2E40.5020707@FreeBSD.org> In-Reply-To: <469D0CFE.2090508@vwsoft.com> References: <200707162319.41724.lofi@freebsd.org> <200707171005.37507.wundram@beenic.net> <469C835B.6090304@vwsoft.com> <200707171106.30795.wundram@beenic.net> <469C8F72.7040500@vwsoft.com> <469CEADF.8090801@FreeBSD.org> <469D0CFE.2090508@vwsoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Volker wrote: > Doug, > > On 07/17/07 18:14, Doug Barton wrote: >> Volker, >> >> 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. Wrong 2. Which in fact means, FreeBSD uses something which is a violation of RFC2870 which is not guaranteed to work. Wrong 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. Wrong 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 named.conf. 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 problem. >> 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 > work 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 > requests. 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 users. >>> 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 > understand? 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 .... Doug -- This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?469D2E40.5020707>