Re: default dns config change causing major poolpah

From: Doug Barton <dougb_at_FreeBSD.org>
Date: Wed, 01 Aug 2007 13:32:42 -0700
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 dns-operations_at_mail.oarc.isc.org).
>> 
>> 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:
> 
> <200707162319.41724.lofi_at_freebsd.org> ("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
Received on Wed Aug 01 2007 - 18:32:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:15 UTC