Re: default dns config change causing major poolpah
Doug Barton wrote this message on Thu, Aug 02, 2007 at 03:14 -0700: I've never trusted using a hints file... not for at least a decade, I'm not sure how the hints file could fail, it's a pretty simple mechanism. But you're better off using hints (which go years between updates, and you only need one good server to get your cache primed anyway) OR AXFR, which will keep itself up to date automatically. I've had the hints file fail on my server multiple times since I've been running my servers... DNS breaks and I get a constast stream of messages that have no relationship to a failure to contact a root server... The first time it happened it took me close to a day to find out that a simple refresh of my hints file fixed the problem... Now, when I see that message, I now know to update my hints file, but it isn't very good to require manual updating of the hints file every few years to stave off broken dns. So, mark on up to supporting a dns based distribution of the root... (Not necessarily using the existing root servers, but some method that will ensure that dns will not break just because it does.) -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
While I think FreeBSD generally should try to push the state of the art envelope, it seems to me that this change may be premature, in particular if the people providing the AXFR-service on which it depends, are not prepared to officially offer the service. So for this change to remain in FreeBSD, one of two things will have to happen: A) At least three (A number found on my paint-bucket) root servers must sign up to provide the public AXFR for at least 3 (ditto) years. or B) FreeBSD systems so configured, shall keep working flawlessly if the AXFR service becomes unavailable. What should not under any circumstances happen: C) The unannounced service is terminated and all so configured FreeBSD systems wedge. That said, I fully agree with the spirit of this change, I have myself seen what positive difference it makes for servers in Denmark to have a slave of the .dk zone, particular for busy mailservers. I hope we can swing for solution A) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Poul-Henning Kamp wrote: That said, I fully agree with the spirit of this change, I have myself seen what positive difference it makes for servers in Denmark to have a slave of the .dk zone, particular for busy mailservers. One of the other objections I have with this change (other than the fact that it was made w/o consultation) is the fact that this is would become the default setting. Yes, busy mail servers may be better served by slaving frequently used zones, and as Vixie mentioned on the dns-operations list, there is less objection if wizards use AXFR, and they would perhaps know more of the pitfalls that doing this entails (vs. relying on hints). But the fact is this is being enabled for every Tom, Dick, and Sarah operating a OS who won't know what the possible ramifications are of this change, and the benefit compared to the downside is nonexistant. And that is *BAD, BAD, BAD*. Has this change been raised on the relevant IETF DNS operations list? These are the defaults we are talking about here. I will reiterate, this change needs to be rolled back until there has been more discussion. dbarton mentioned earlier that root operators make changes on a glacial scale. There is a reason for that. ;) Best Wishes - Peter -- [EMAIL PROTECTED] | ISC | OpenPGP 0xE8048D08 | The bits must flow signature.asc Description: OpenPGP digital signature
Re: default dns config change causing major poolpah
In message [EMAIL PROTECTED], Peter Losher writes: One of the other objections I have with this change (other than the fact that it was made w/o consultation) is the fact that this is would become the default setting. I don't have data to judge the impact. I just tried it on one of my machines and it looks like 100K of slave files but I don't know the impact of that, relative to all the junk queries it saves. That said, I would certainly have started it out as a named_experimental_root_axfr=NO option myself, rather than to make it te default default. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Peter Losher wrote: One of the other objections I have with this change (other than the fact that it was made w/o consultation) is the fact that this is would become the default setting. Yes, busy mail servers may be better served by slaving frequently used zones, and as Vixie mentioned on the dns-operations list, there is less objection if wizards use AXFR, and they would perhaps know more of the pitfalls that doing this entails (vs. relying on hints). But the fact is this is being enabled for every Tom, Dick, and Sarah operating a OS who won't know what the possible ramifications are of this change, and the benefit compared to the downside is nonexistant. And that is *BAD, BAD, BAD*. Has this change been raised on the relevant IETF DNS operations list? These are the defaults we are talking about here. On the ramifications - I run named purely as a caching resolver (my isp's dns servers are pathetically slow)... and I was somewhat surprised to discover that I'm *now* slaving zones from the root servers - it's not that I'm especially stupid (I hope...), but rather that I set this up before this change came into effect and didn't notice it during (presumably) mergemaster. The thing that concerns me now is this: are there many folks in a similar situation, are we gonna be unwittingly hammering these root servers? regards Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Hi, Regardless of the technicalities and politics, this change is obviously a major POLA violation which is a good enough reason to back it out. -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
On Wed, 2007-08-01 at 18:04 -1000, Randy Bush wrote: in addition nowhere does it state in RFC2870 that the root-servers have to accept AXFR's as part of their service. in fact, the opposite 2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, queries from clients other than other root servers. This restriction is intended to, among other things, prevent unnecessary load on the root servers as advice has been heard such as To avoid having a corruptible cache, make your server a stealth secondary for the root zone. The root servers MAY put the root zone up for ftp or other access on one or more less critical servers. I think this makes it completely clear that we should not be trying to use the AXFR service from any of the root servers. Expert users can do what they like but making our default configuration use a service which is documented in the current best practices document as being unsupported seems foolish. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Matthew Dillon wrote: I generally recommend using our 'getroot' script to download an actual root.zone file instead of using a hints file (and I guess AXFR is supposed to replace both concepts). Yes to AXFR replacing both, but ... It has always seemed to me that actually downloading a physical root zone file once a week is the most reliable solution. This is a really bad idea. The root zone changes slowly, but it often changes more than once a week. Add to that the more-rapid deployment of new TLDs nowadays and the occasional complete reprovisioning of an existing TLD, and one week is too long to go between updates. I've never trusted using a hints file... not for at least a decade, I'm not sure how the hints file could fail, it's a pretty simple mechanism. But you're better off using hints (which go years between updates, and you only need one good server to get your cache primed anyway) OR AXFR, which will keep itself up to date automatically. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Doug, good day. Thu, Aug 02, 2007 at 03:14:38AM -0700, Doug Barton wrote: Matthew Dillon wrote: It has always seemed to me that actually downloading a physical root zone file once a week is the most reliable solution. This is a really bad idea. The root zone changes slowly, but it often changes more than once a week. Add to that the more-rapid deployment of new TLDs nowadays and the occasional complete reprovisioning of an existing TLD, and one week is too long to go between updates. But if one will pull the root zone via FTP/HTTP at the zone's refresh rate or so -- will it be still a bad idea, compared to the AXFR method? -- Eygene ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
On Thu, Aug 02, 2007 at 06:26:46AM +0200, Thijs Eilander wrote: If there is a consensus based on solid technical reasons (not emotion or FUD) to back the root zone slaving change out, I'll be glad to do so. I think it would be very useful at this point if those who _like_ the change would speak up publicly as well. For starters, I am doing it since 1998 (and not only in named) on busy dns servers. I like the idea but not the change. Motivation: 1) Not everyone is an admin on a busy nameservers. Is it really necessary to include it in the distribution? A lot of people don't even get it, they just setup their homemade firewall/dnsserver. Do those people need to slave the rootservers by default? Why? 2) Skilled administrators are aware of the slave trick, or they fetch root.zone.gz once a week. Why include it for the skilled at expense of the clueless people from argument 1 ? i am not a 'skilled administrator' i'd probably not quite make it to clueless user status, as yet, but i am working on it .. some ten years and prior to that and my accident some 15 yeasr on qnx and os9: level I and level II (note i am disbled man, born with damaged brain --- memory disabilities and learning skills defeciets as well as motor skills deficiencies .. please excuse my typing) Why not fetching the root.zone.gz file itself once a week? Matthew Dillon send a nice getroot script to this discussion, I think we should put an adjusted script in /etc/periodic/weekly. this seems to be a cleaner way than using axfr on rootservers which don't notify us on changes. (Benefit: the root.zone.gz is signed, axfr probably not). i am not claiming to understad the issues involved, i've asked off list and am waiting for replies .. hopefully they will come. but given from what i have read and understand of teh tasks involved and teh load issues and so forth i think that this would be a really good idea. most new users havent got a hope of understanding what is going on .. i have just upgraded my whole netowrk from 25 year old 386dx33 machines to 10 year old cpmpaq proliant 5500 (2 off with 4 cpu 4 gb dram and nice scsi raid onboard and a proliant 1850r with 2 cpu and 2 gb dram i think) but more importantly the software went from freebsd v2.2.5-R to v6.2-R and i have found that it might have been easier to dump freebsd and got with netbsd/openbsd something like that. there are a lot of difference and its a steep learning curve for a new user or an old user with some significant learning defeciets like me. my network is connect to teh backbone via perment dialup modem and the new named is having issues/squables with ppp/pppd i've been a devout pppd user some 10 years, i think that pppd is just the way that it should be done, a personal opoinion nothing more onthing less. i get hourly reminder in /var/log/messages about permissions/interface dropped named ignoring the port. locally dns seems to be working on teh bind 9.?.? (3 something) but i don't know if its being seen outside if any of my secondaries are getting thier data streams. at forst it seems to be a firewall issue, so after giving up trying to make teh jump from v2.2.5 edition ipfw to teh current one with v6.2 i gave up and asked a friend for help with setting up pf, as far as i can tell pf is doing its job and i've dismantled all teh ipfw stuff on teh 6 or so servers handling teh getway (fidonet to/from usenet) and now the gatewy machine is runnign pf and the sshd attack/probes have stoped (i seems) but my named is still complaining hourly about thes ports/permissions errors that it was complaing about with pppd and ipfw i have scoured teh handbook, the faq even teh fabled google and there is precious little, whatever there is relates to some obscure linux dns running in a jailed environment .. i tried de jailing, sorry that is not the corect term but the best that i can do without making a major effort to dig it out of teh relevent dooc sets. it is things like this that make arbitrary desisions/changes to untime/production environments a real pain .. i suppose if i were a real administrator i'd have teh skills to diagnose this problem but the reality is that i am a special trying to overcome th bigotry and out right discrimination that ihave come to sxpect as my lot in life, thankfully it is not so bad here in freebsd land .. but it rears its had to remind me that i'm not in heave, just quite yet, big grin, ok. Personally I think this serves the same goal and hopefully in a less annoying way, without having to worry (or argue!) about axfr is still allowed for at least next 2 years. this sounds really good to me, hopefully some level of sanity might prevail Just another 2 cents for in your moneybag, what will you do with all those 'funding' ? :) and another 2 australian cents from me, thijs .. thanks for writing you good article as always please excuse teh poor writing/typing and grammer kind regards jonathan --
Re: Re: default dns config change causing major poolpah
On 12/23/-58 20:59, Doug Barton wrote: Jo Rhett wrote: On Wed, Aug 01, 2007 at 01:32:42PM -0700, Doug Barton wrote: This is about on par with unnamed network equipment manufacturer selling SOHO routers that synchronize their clocks using stratum-1 NTP servers. I don't really think that analogy holds up, given that those who run public stratum-1 NTP servers specifically request that individual hosts not sync from them. The analogy is more true than you believe. Someone told you on this very same list that it was not allowed, If you're talking about Volker I have already explained at great length why he was flat out wrong on just about every particular. Anyone interested can read the archives around 7/17. Well, my fault was to post to the mailing list before checking what has been changed in cvs and this caused me to post about an assumption instead of information and checked cvs later. On the other hand, your postings sounded more likely to be flames as you did not really said something about the issue itself but picked on some bad formulation from a non-native english speaker. But as I wrote you already in private mail, I don't like to discuss further and this is my last word on that topic. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
On Wed, 01 Aug 2007 13:32:42 -0700 Doug Barton [EMAIL PROTECTED] wrote: The root server operators do not make changes in this kind of abrupt fashion. This, I think, is the root (sic) of the objections here in FreeBSD land. I expect many people think the same of the FreeBSD project - that it won't make changes of this kind in a abrubt fashion, but that is exactly what has happened here. When I was updating, mergemaster highlighted the change and I thought, How odd, I guess I missed that announcement, and merrily zapped it with my existing config. I didn't get upset, partly because I didn't really think very hard about the impact, but mostly because I assumed I was at fault for having missed the heads-up about it. As to what the default should be, I don't know, that's for all you smart people out there to debate so that the rest of us, who are eternally indebted to you, don't have to. I suspect that the vast majority of users also don't have an opinion either way, but enjoy hanging out in the bikeshed, just like me. -fr. -- Feargal Reilly, Chief Techie, FBI. PGP Key: 0xBD252C01 (expires: 2006-11-30) Web: http://www.fbi.ie/ | Tel: +353.14988588 | Fax: +353.14988489 Communications House, 11 Sallymount Avenue, Ranelagh, Dublin 6. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
On Tue, 31 Jul 2007, Randy Bush wrote: the undiscussed and unannounced change to the default dns config to cause local transfer of the root and arpa zone files has raised major discussing in the dns operational community. (see the mailing list [EMAIL PROTECTED]). How may viewing these mailing list postings be achieved? Interested, Ian. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
On Wed, Aug 01, 2007 at 04:15:32PM +1000, Ian Smith wrote: On Tue, 31 Jul 2007, Randy Bush wrote: the undiscussed and unannounced change to the default dns config to cause local transfer of the root and arpa zone files has raised major discussing in the dns operational community. (see the mailing list [EMAIL PROTECTED]). How may viewing these mailing list postings be achieved? Good starting point: http://lists.oarci.net/pipermail/dns-operations/2007-July/001803.html Same thread continues on into 2007 of August. http://lists.oarci.net/pipermail/dns-operations/2007-August/thread.html dougb@, I hope you're reading those. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
[current@ omitted, I'm not subscribed so it whinges] On Wed, 1 Aug 2007, Jeremy Chadwick wrote: On Wed, Aug 01, 2007 at 04:15:32PM +1000, Ian Smith wrote: On Tue, 31 Jul 2007, Randy Bush wrote: the undiscussed and unannounced change to the default dns config to cause local transfer of the root and arpa zone files has raised major discussing in the dns operational community. (see the mailing list [EMAIL PROTECTED]). How may viewing these mailing list postings be achieved? Good starting point: http://lists.oarci.net/pipermail/dns-operations/2007-July/001803.html Same thread continues on into 2007 of August. http://lists.oarci.net/pipermail/dns-operations/2007-August/thread.html Thanks. Informative and very spirited discussion as expected. I wasn't at all surprised to see Paul Vixie's first comment: this is a really, really, really terrible idea. but he might be a tad molified by now. dougb@, I hope you're reading those. :-) Powder kept dry until: http://lists.oarci.net/pipermail/dns-operations/2007-August/001856.html Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Am Mittwoch 01 August 2007 13:07:27 schrieb Skip Ford: snip You might want to check the thread starting with: [EMAIL PROTECTED] (Problems with named default configuration in 6-STABLE) also on freebsd-stable, where quite some discussion on this topic already took place. -- Heiko Wundram Product Application Development ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Randy Bush wrote: the undiscussed and unannounced change to the default dns config to cause local transfer of the root and arpa zone files has raised major discussing in the dns operational community. (see the mailing list [EMAIL PROTECTED]). did i miss the discussion here? No. There was none. i have spent some hours turning off the default bind and going custom on a dozen or so machines around the planet. i am not happy. what am i missing here? I don't have an axe to grind. I don't run the default config on any of my 2 dozen name servers (not all of which run bind anyway) so I wasn't really affected by the change. However, I thought it was a really, really, terrible idea, and a rather rude act considering it relies on the charity of others to not break. There is no requirement that FreeBSD users be permitted to slave the roots. Everyone who uses the default config can have their setups broken the day after installation. We never asked permission to use the resources of others in this way, and they're not required to allow us to do so. It's rude to assume they'll allow it, and it's risky to not receive permission beforehand to ensure slaving the roots will continue to work after RELEASE. The original commit message for the change indicated it was done to bring us in line with current best practices but that commit message is the only place I have ever seen anyone say that slaving the roots is current best practice. Again, I don't have an axe to grind and I really don't want to get in the middle of a personal attack. I don't think the world will explode, and in reality, there will probably be no problems at all, but if there aren't, it's because of pure luck not good planning or decision making. Microsoft makes much worse assumptions about the availability of the resources of others, but this is a Microsoft-ish decision, IMO. Just not a good plan. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Randy Bush [EMAIL PROTECTED] writes: the undiscussed and unannounced change to the default dns config to cause local transfer of the root and arpa zone files has raised major discussing in the dns operational community. (see the mailing list [EMAIL PROTECTED]). This is about on par with unnamed network equipment manufacturer selling SOHO routers that synchronize their clocks using stratum-1 NTP servers. It should be backed out with prejudice. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Replying en masse to bring related thoughts together. It was already posted, but a more complete treatment of my reasoning is found at: http://lists.oarci.net/pipermail/dns-operations/2007-August/001856.html Skip Ford wrote: Randy Bush wrote: the undiscussed and unannounced change to the default dns config to cause local transfer of the root and arpa zone files has raised major discussing in the dns operational community. (see the mailing list [EMAIL PROTECTED]). did i miss the discussion here? No. There was none. i have spent some hours turning off the default bind and going custom on a dozen or so machines around the planet. i am not happy. Randy, You might make your life a little easier by checking out src.conf(1) in 7-current and make.conf(1) in 6-stable which both document the various NO_BIND_* knobs that are available. What you probably want is NO_BIND_ETC. I don't have an axe to grind. I don't run the default config on any of my 2 dozen name servers (not all of which run bind anyway) so I wasn't really affected by the change. However, I thought it was a really, really, terrible idea, You're entitled to your opinion. If you take a look at the thread on the dns-operations list you'll see that there are a lot of really smart people lined up on both sides of this argument. and a rather rude act considering it relies on the charity of others to not break. The same can be said of the root server network in general. There is no requirement that FreeBSD users be permitted to slave the roots. Everyone who uses the default config can have their setups broken the day after installation. The root server operators do not make changes in this kind of abrupt fashion. We never asked permission to use the resources of others in this way, and they're not required to allow us to do so. Once again, the same is true of resolution from the root servers as well. The original commit message for the change indicated it was done to bring us in line with current best practices but that commit message is the only place I have ever seen anyone say that slaving the roots is current best practice. The BCP comment you're referring to was in regards to the default localhost zone generation which is not in any way related. Please see: http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/namedb/named.conf Heiko Wundram (Beenic) wrote: Am Mittwoch 01 August 2007 13:07:27 schrieb Skip Ford: snip You might want to check the thread starting with: [EMAIL PROTECTED] (Problems with named default configuration in 6-STABLE) Easier for most folks to access this by: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=207558+0+archive/2007/freebsd-stable/20070722.freebsd-stable That thread involved an issue of resolving local zones that could not be resolved because of a combination of slaving the root zone and the new default empty reverse zones for RFC 1918 space; and how that interacted with the forwarders clause that user had in his config. Dag-Erling Smørgrav wrote: This is about on par with unnamed network equipment manufacturer selling SOHO routers that synchronize their clocks using stratum-1 NTP servers. I don't really think that analogy holds up, given that those who run public stratum-1 NTP servers specifically request that individual hosts not sync from them. The root server operators have a choice of whether to enable AXFR or not. Also, that configuration could not be changed, but named.conf can be changed easily. If there is a consensus based on solid technical reasons (not emotion or FUD) to back the root zone slaving change out, I'll be glad to do so. I think it would be very useful at this point if those who _like_ the change would speak up publicly as well. Regards, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
On Wed, Aug 01, 2007 at 01:32:42PM -0700, Doug Barton wrote: This is about on par with unnamed network equipment manufacturer selling SOHO routers that synchronize their clocks using stratum-1 NTP servers. I don't really think that analogy holds up, given that those who run public stratum-1 NTP servers specifically request that individual hosts not sync from them. The analogy is more true than you believe. Someone told you on this very same list that it was not allowed, and you argued that it wasn't denied therefore it should be okay. You're doing an excellent job of ignoring contrary opinions and reinventing facts. And the very same root operators are on dns-operations list telling you not to do this, and you are ignoring them there too. If there is a consensus based on solid technical reasons (not emotion or FUD) to back the root zone slaving change out, I'll be glad to do so. I think it would be very useful at this point if those who _like_ the change would speak up publicly as well. Everyone has spoken up, and you've ignored every one of them. Including the root operators themselves. Because they are unable to convince you, they're going to have to disable AXFR and break a lot of things all over the world to get this stupidity stopped. -- Jo Rhett senior geek Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Doug Barton wrote: If there is a consensus based on solid technical reasons (not emotion or FUD) to back the root zone slaving change out, If that's a shot at me, you're out of line. I specifically said I didn't have an axe to grind with anyone, and I never piled on in my comments. The reason I provided *is* purely technical. The roots can decide tomorrow to block AXFR requests from FreeBSD users who install 6.3-RELEASE or 7.0-RELEASE. They may. They may not. But they can. It's not a production feature and therefore should not be relied upon. If the operators state they will support AXFR for the life of those releases, I have no objections. Such a statement would indicate all at once that they don't mind the traffic and that such a config will not break. I haven't kept up-to-date with cached(8) but if we're able to cache lookups now without a name server, we don't even need BIND in the base system anymore IMO. We still have very well maintained ports. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Doug Barton wrote: Replying en masse to bring related thoughts together. It was already posted, but a more complete treatment of my reasoning is found at: http://lists.oarci.net/pipermail/dns-operations/2007-August/001856.html Skip Ford wrote: Randy Bush wrote: the undiscussed and unannounced change to the default dns config to cause local transfer of the root and arpa zone files has raised major discussing in the dns operational community. (see the mailing list [EMAIL PROTECTED]). did i miss the discussion here? No. There was none. i have spent some hours turning off the default bind and going custom on a dozen or so machines around the planet. i am not happy. Randy, You might make your life a little easier by checking out src.conf(1) in 7-current and make.conf(1) in 6-stable which both document the various NO_BIND_* knobs that are available. What you probably want is NO_BIND_ETC. I don't have an axe to grind. I don't run the default config on any of my 2 dozen name servers (not all of which run bind anyway) so I wasn't really affected by the change. However, I thought it was a really, really, terrible idea, You're entitled to your opinion. If you take a look at the thread on the dns-operations list you'll see that there are a lot of really smart people lined up on both sides of this argument. and a rather rude act considering it relies on the charity of others to not break. The same can be said of the root server network in general. There is no requirement that FreeBSD users be permitted to slave the roots. Everyone who uses the default config can have their setups broken the day after installation. The root server operators do not make changes in this kind of abrupt fashion. We never asked permission to use the resources of others in this way, and they're not required to allow us to do so. Once again, the same is true of resolution from the root servers as well. The original commit message for the change indicated it was done to bring us in line with current best practices but that commit message is the only place I have ever seen anyone say that slaving the roots is current best practice. The BCP comment you're referring to was in regards to the default localhost zone generation which is not in any way related. Please see: http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/namedb/named.conf Heiko Wundram (Beenic) wrote: Am Mittwoch 01 August 2007 13:07:27 schrieb Skip Ford: snip You might want to check the thread starting with: [EMAIL PROTECTED] (Problems with named default configuration in 6-STABLE) Easier for most folks to access this by: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=207558+0+archive/2007/freebsd-stable/20070722.freebsd-stable That thread involved an issue of resolving local zones that could not be resolved because of a combination of slaving the root zone and the new default empty reverse zones for RFC 1918 space; and how that interacted with the forwarders clause that user had in his config. Dag-Erling Smørgrav wrote: This is about on par with unnamed network equipment manufacturer selling SOHO routers that synchronize their clocks using stratum-1 NTP servers. I don't really think that analogy holds up, given that those who run public stratum-1 NTP servers specifically request that individual hosts not sync from them. The root server operators have a choice of whether to enable AXFR or not. Also, that configuration could not be changed, but named.conf can be changed easily. If there is a consensus based on solid technical reasons (not emotion or FUD) to back the root zone slaving change out, I'll be glad to do so. I think it would be very useful at this point if those who _like_ the change would speak up publicly as well. Regards, Doug I like the change! -- Kind regards, Remko Lodder ** [EMAIL PROTECTED] FreeBSD** [EMAIL PROTECTED] /* Quis custodiet ipsos custodes */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Skip Ford wrote: Doug Barton wrote: If there is a consensus based on solid technical reasons (not emotion or FUD) to back the root zone slaving change out, If that's a shot at me, you're out of line. It wasn't aimed specifically at you, no. I specifically said I didn't have an axe to grind with anyone, and I never piled on in my comments. Reasonable minds may differ on that, but in any case ... The reason I provided *is* purely technical. The roots can decide tomorrow to block AXFR requests from FreeBSD users who install 6.3-RELEASE or 7.0-RELEASE. They may. They may not. But they can. Here is where the problem lies. What you're saying here is simply not true. I know several of the root operators personally, and in my previous position as GM of IANA I worked with them directly both individually and collectively. Everything involving a change to a root server is done at a near-glacial pace. There no more danger that we will wake up tomorrow unable to AXFR the root from any server than there is that we'll wake up tomorrow not able to send resolver queries to any root server. To say that this IS possible is FUD. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Jo Rhett wrote: On Wed, Aug 01, 2007 at 01:32:42PM -0700, Doug Barton wrote: This is about on par with unnamed network equipment manufacturer selling SOHO routers that synchronize their clocks using stratum-1 NTP servers. I don't really think that analogy holds up, given that those who run public stratum-1 NTP servers specifically request that individual hosts not sync from them. The analogy is more true than you believe. Someone told you on this very same list that it was not allowed, If you're talking about Volker I have already explained at great length why he was flat out wrong on just about every particular. Anyone interested can read the archives around 7/17. and you argued that it wasn't denied therefore it should be okay. You're doing an excellent job of ignoring contrary opinions and reinventing facts. Actually I have not ignored contrary opinions, I've stated explicitly that there are contrary opinions. Anyone interested is free to read the archives of the dns-operations list where I think both sides of the argument are presented pretty well. But there is a difference between yes, there are contrary opinions that I don't agree with based on my actual experience with the topic and If anyone disagrees with something, it must be wrong. I would like to suggest that if you are actually interested in a debate about the _merits_ of the change that you look at my post here:http://lists.oarci.net/pipermail/dns-operations/2007-August/001856.html, then read the paper by David Malone that is mentioned in that article, then read the rest of the thread on that list. If you don't have at least that much background on the topic we're just wasting time here. And the very same root operators are on dns-operations list telling you not to do this, and you are ignoring them there too. Three root operators (two of whom are in named.conf right now) have spoken up on that list. Of the two that actually offer AXFR, one has said paraphrasing I hate this idea, but I won't disable AXFR because of it. One has said, please remove B from your list/distribution until you have received permission from the FreeBSD community that this change is what they want. Since that condition is so incredibly arbitrary as to be essentially meaningless, I am going to remove that server. If there is a consensus based on solid technical reasons (not emotion or FUD) to back the root zone slaving change out, I'll be glad to do so. I think it would be very useful at this point if those who _like_ the change would speak up publicly as well. Everyone has spoken up, and you've ignored every one of them. Are you ignoring the people who've spoken up saying that they like the change, and that they think it's a good idea? Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
However, I thought it was a really, really, terrible idea, You're entitled to your opinion. If you take a look at the thread on the dns-operations list you'll see that there are a lot of really smart people lined up on both sides of this argument. which, to some of us, would have been a clue not to make a change with no discussion randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Randy Bush wrote: However, I thought it was a really, really, terrible idea, You're entitled to your opinion. If you take a look at the thread on the dns-operations list you'll see that there are a lot of really smart people lined up on both sides of this argument. which, to some of us, would have been a clue not to make a change with no discussion So no changes should be made unless everyone agrees? -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
On Wed, 01 Aug 2007, at 16:12, Doug Barton wrote: So no changes should be made unless everyone agrees? no way everybody would agree on that. However: . you would have made your change with some support (presumably) in the freebsd community, and with the benediction (or at least no opposition) from the rootops . everybody would have been aware of the upcoming change Look, now you were asked to remove b - all of this could have been avoided with some appropriate PR ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
which, to some of us, would have been a clue not to make a change with no discussion So no changes should be made unless everyone agrees? you made the leap from discussion to unanimity, not i. i do not think the latter possible. but that is a long way from the freebsdish thinking of the following change. what you did was penguin land. randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Doug Barton wrote: Skip Ford wrote: The reason I provided *is* purely technical. The roots can decide tomorrow to block AXFR requests from FreeBSD users who install 6.3-RELEASE or 7.0-RELEASE. They may. They may not. But they can. Here is where the problem lies. What you're saying here is simply not true. I know several of the root operators personally, and in my previous position as GM of IANA I worked with them directly both individually and collectively. Everything involving a change to a root server is done at a near-glacial pace. There no more danger that we will wake up tomorrow unable to AXFR the root from any server than there is that we'll wake up tomorrow not able to send resolver queries to any root server. To say that this IS possible is FUD. So, it seems simple enough then if what you're saying is true. Have your friends running the roots state that they will support our AXFRs. I will have no objections once they do that. It's a randomly provided service already. Not all of them answer AXFR now, so how many of them will 2 years from now is a legitimate question, and is my only concern. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
So no changes should be made unless everyone agrees? IMO, when the issue is split as such, that means no change. I would have instead offered a sample config with clear documentation saying what the intent of that specific sample was for; but the stock config would have been much as it was before the change. (Even if I'm *personally* interested in this option.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
On Wed, 01 Aug 2007, at 13:32, Doug Barton wrote: If there is a consensus based on solid technical reasons (not emotion or FUD) to back the root zone slaving change out, I'll be glad to do so. I think it would be very useful at this point if those who _like_ the change would speak up publicly as well. Ok - I do like the change I do think still that it should have been discussed publicly on -arch as well as with the rootops / dns-ops ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
* Doug Barton ([EMAIL PROTECTED]) wrote: If there is a consensus based on solid technical reasons (not emotion or FUD) to back the root zone slaving change out, I'll be glad to do so. I think it would be very useful at this point if those who _like_ the change would speak up publicly as well. The abstract at the top of David Malone's paper says: Tests, described here, indicate that this technique seems to be comparable to the traditional hints mechanism for moderately busy name servers and may offer other benefits Indeed the paper, various messages in dns-operations and so forth would seem to suggest this is more of use for busier systems with hundreds if not thousands of users. These installs are probably something of a minority, and more to the point are more likely to have had a reasonable amount of time and research spent poking at configs. Many more smaller installs are probably going to be thrown up by people with less interest in such; Oh, I just want a resolver and some local DNS names for my 2 user home network/10 user business, I guess the default config will be fine. I would suggest that the commented bits be reversed; have a hints file as the default, more traditional, less controversial option, with slave zones commented out, with a more explicit note about when and why it might be helpful, and mentioning any caveats re smaller installs, less root server support, Paul Vixie kicking puppies, etc. Even if slave zones are generally better, I would still think the more conservative approach would be the better one, especially in 6.*. -- Thomas 'Freaky' Hurst http://hur.st/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Yann Berthier wrote: On Wed, 01 Aug 2007, at 16:12, Doug Barton wrote: So no changes should be made unless everyone agrees? no way everybody would agree on that. However: . you would have made your change with some support (presumably) in the freebsd community, and with the benediction (or at least no opposition) from the rootops . everybody would have been aware of the upcoming change Look, now you were asked to remove b - all of this could have been avoided with some appropriate PR You're right about more PR in advance being a good thing, and for the lack of that, I apologize. I don't think that all of the drama could have been avoided in any case, there is too much emotion surrounding this issue. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
I don't think that all of the drama could have been avoided in any case, there is too much emotion surrounding this issue. I'll concur with Doug on this. I've been discussing doing just this for the last 10+ years. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Mark Andrews wrote: I don't think that all of the drama could have been avoided in any case, there is too much emotion surrounding this issue. I'll concur with Doug on this. I've been discussing doing just this for the last 10+ years. Why don't you update 2870 then to make it so? If all the roots provided it and were required to, there's no problem. But current best practice as defined by 2870 are for roots to only answer AXFRs from other roots. How can you advocate an OS pushing a configuration that isn't guaranteed to be functional? I understand the odds of it breaking, and I understand the benefits. That's not the issue. This is a configuration that should be guaranteed to work for 2 years after every OS release that includes it. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Mark Andrews wrote: I don't think that all of the drama could have been avoided in any case, there is too much emotion surrounding this issue. I'll concur with Doug on this. I've been discussing doing just this for the last 10+ years. Why don't you update 2870 then to make it so? Why don't you? You seem to be the one worried about it :-) I want to get draft-ietf-dnsop-default-local-zones through first before dealing with the issue of how to get every iterative resolver serving the root. You will note that dealing with traffic at the root is left out of draft-ietf-dnsop-default-local-zones. If all the roots provided it and were required to, there's no problem. But current best practice as defined by 2870 are for roots to only answer AXFRs from other roots. How can you advocate an OS pushing a configuration that isn't guaranteed to be functional? I understand the odds of it breaking, and I understand the benefits. That's not the issue. There is a difference between saying we should do this and just doing it. Part of process is to get consenus that this is reasonable or at least won't hurt and working what needs to be changed to make it happen. This is a configuration that should be guaranteed to work for 2 years after every OS release that includes it. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Doug Barton wrote: Here is where the problem lies. What you're saying here is simply not true. I know several of the root operators personally, and in my previous position as GM of IANA I worked with them directly both individually and collectively. Everything involving a change to a root server is done at a near-glacial pace. There no more danger that we will wake up tomorrow unable to AXFR the root from any server than there is that we'll wake up tomorrow not able to send resolver queries to any root server. To say that this IS possible is FUD. Doug - that is a *BIG* assumption you just made there. As far as I know you didn't discuss this change with any of the root server operators (you certainly didn't with ISC) and we could have told you then how bad of a idea this was. It seems you made this change on instinct, and in addition nowhere does it state in RFC2870 that the root-servers have to accept AXFR's as part of their service. You just made with this change what was before a diagnostic service into a production service and you didn't even ask the folks most affected by it. This change should be yanked and yanked now until at least there has been some discussion with the root server operators. (and discussing it on the dns-operations@ list does not cut it) -Peter (with his root-ops hat on his desk) -- [EMAIL PROTECTED] | ISC | OpenPGP 0xE8048D08 | The bits must flow signature.asc Description: OpenPGP digital signature
Re: default dns config change causing major poolpah
Mark Andrews wrote: I don't think that all of the drama could have been avoided in any case, there is too much emotion surrounding this issue. I'll concur with Doug on this. I've been discussing doing just this for the last 10+ years. Why don't you update 2870 then to make it so? Why don't you? You seem to be the one worried about it :-) I just figured you'd be able to snap your fingers, click your heels, and be done with it. I want to get draft-ietf-dnsop-default-local-zones through first before dealing with the issue of how to get every iterative resolver serving the root. FWIW, I reviewed your draft back in March and had no objections. :-) If all the roots provided it and were required to, there's no problem. But current best practice as defined by 2870 are for roots to only answer AXFRs from other roots. How can you advocate an OS pushing a configuration that isn't guaranteed to be functional? I understand the odds of it breaking, and I understand the benefits. That's not the issue. There is a difference between saying we should do this and just doing it. Part of process is to get consenus that this is reasonable or at least won't hurt and working what needs to be changed to make it happen. Ah, sorry for putting words in your mouth then. Now I understand, and I agree. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
The vast majority of machine installations just slave their dns off
of another machine, and because of that I do not think it is particularly
odious to require some level of skill for those who actually want to set
up their own server.
To that end what I do on DragonFly is simply supply a README file in
/etc/namedb along with a few helper scripts describing how to do it in
a fairly painless manner. If a user cannot understand the README then
he has no business setting up a DNS server anyhow. Distributions need to
be fairly sensitive to doing anything that might accidently (through lack
of understanding) cause an overload of critical internet resources.
http://www.dragonflybsd.org/cvsweb/src/etc/namedb/
I generally recommend using our 'getroot' script to download an actual
root.zone file instead of using a hints file (and I guess AXFR is supposed
to replace both concepts). It has always seemed to me that actually
downloading a physical root zone file once a week is the most reliable
solution.
I've never trusted using a hints file... not for at least a decade,
and I probably wouldn't trust AXFR for the same reason. Probably my
mistrust is due to the massive problems I had using a hints file long
ago and I'm sure it works better these days, but I've never found any
reason to switch back from an actual root.zone.
I've enclosed the getroot script we ship below. In anycase, it seems
to me that there is no good reason to try to automate dns services as
a distribution default in the manner being described. Just my
two-cents.
-Matt
#!/bin/tcsh -f
#
# If you are running named and using root.zone as a master, the root.zone
# file should be updated periodicly from ftp.rs.internic.net.
#
# $DragonFly: src/etc/namedb/getroot,v 1.2 2005/02/24 21:58:20 dillon Exp $
cd /etc/namedb
umask 027
set hostname = 'ftp.rs.internic.net'
set remfile = domain/root.zone.gz
set locfile = root.zone.gz
set path = ( /bin /usr/bin /sbin /usr/sbin )
fetch ftp://${hostname}:/${remfile}
if ( $status != 0) then
rm -f ${locfile}
echo Download failed
else
gunzip ${locfile} root.zone.new
if ( $status == 0 ) then
rm -f ${locfile}
if ( -f root.zone ) then
mv -f root.zone root.zone.bak
endif
chmod 644 root.zone.new
mv -f root.zone.new root.zone
echo Download succeeded, restarting named
rndc reload
sleep 1
rndc status
else
echo Download failed: gunzip returned an error
rm -f ${locfile}
endif
endif
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
in addition nowhere does it state in RFC2870 that the root-servers have to accept AXFR's as part of their service. in fact, the opposite 2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, queries from clients other than other root servers. This restriction is intended to, among other things, prevent unnecessary load on the root servers as advice has been heard such as To avoid having a corruptible cache, make your server a stealth secondary for the root zone. The root servers MAY put the root zone up for ftp or other access on one or more less critical servers. randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: default dns config change causing major poolpah
If there is a consensus based on solid technical reasons (not emotion or FUD) to back the root zone slaving change out, I'll be glad to do so. I think it would be very useful at this point if those who _like_ the change would speak up publicly as well. For starters, I am doing it since 1998 (and not only in named) on busy dns servers. I like the idea but not the change. Motivation: 1) Not everyone is an admin on a busy nameservers. Is it really necessary to include it in the distribution? A lot of people don't even get it, they just setup their homemade firewall/dnsserver. Do those people need to slave the rootservers by default? Why? 2) Skilled administrators are aware of the slave trick, or they fetch root.zone.gz once a week. Why include it for the skilled at expense of the clueless people from argument 1 ? An idea: Why not fetching the root.zone.gz file itself once a week? Matthew Dillon send a nice getroot script to this discussion, I think we should put an adjusted script in /etc/periodic/weekly. this seems to be a cleaner way than using axfr on rootservers which don't notify us on changes. (Benefit: the root.zone.gz is signed, axfr probably not). Personally I think this serves the same goal and hopefully in a less annoying way, without having to worry (or argue!) about axfr is still allowed for at least next 2 years. Just another 2 cents for in your moneybag, what will you do with all those 'funding' ? :) With kind regards, Thijs Eilander ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
In message: [EMAIL PROTECTED] Randy Bush [EMAIL PROTECTED] writes: : However, I thought it was a really, really, terrible idea, : You're entitled to your opinion. If you take a look at the thread on : the dns-operations list you'll see that there are a lot of really : smart people lined up on both sides of this argument. : : which, to some of us, would have been a clue not to make a change : with no discussion I tend to agree. In general in FreeBSD, when there's no consensus for a change, then the change doesn't happen. When there is a change that causes contention, typically, it is backed out until consensus can be reached. I'm not sure what the right thing to do here is, but when I see Paul Vixie say a change is bad, I tend to think long and hard about why I think it is right. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
default dns config change causing major poolpah
the undiscussed and unannounced change to the default dns config to cause local transfer of the root and arpa zone files has raised major discussing in the dns operational community. (see the mailing list [EMAIL PROTECTED]). did i miss the discussion here? i have spent some hours turning off the default bind and going custom on a dozen or so machines around the planet. i am not happy. what am i missing here? randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
