[Unbound-users] Delegation-only zones and non-root zone RFC 5011?

[Johan Ihrén]

Hi,

On 18 Jan 2015, at 19:15 , Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:

> On Sun, Jan 18, 2015 at 12:28:55AM +0100, Florian Weimer wrote:
> 
>>> It would be nice if unbound were able to enforce "delegation-only"
>>> zones that contain only delegations and glue.  This would be useful
>>> for the root zone and various TLDs.  Otherwise, such zones can
>>> return apparently valid signed responses that should have been
>>> delegated to a child zone, but for some reason were not.
>> 
>> There are very few strictly-delegation-only zones, and zones change
>> there status over time, so this feature seems fairly risky.  The ISC
>> recommendations for BIND make recursors subject to denial-of-service
>> attacks that prevent name resolution for entire TLDs.
> 
> Is the root zone at least compatible with a "delegation-only" policy?
> Can you be a bit more specific about the DoS?
> 
> I've certainly seen ccTLD zones that are not delegation-only, for
> example "nic.li" is a CNAME for "switch.ch".  That clearly is
> neither a delegation nor glue, so "li" is not "delegation-only".

To show an example of Florians point: once there were a bunch of TLDs that were technically "delegation-only" and another bunch which was not. ISC went ahead with the delegation-only thing together with a default config which claimed that at least one TLD of the latter kind was "delegation-only". With that code shipped to a large fraction of the BIND9 user base this TLD... felt the pain (as the story goes). In the end, realizing there was no way to get this fixed they realized that their only real alternative was to restructure the TLD to become "delegation only".

So utterly broken. So full of wrong. So not a responsible software design design.

> Without some constraints on which queries the root, gTLD and ccTLD
> can choose to answer rather than delegate, it seems difficult to
> make "transparency" work for DNSSEC.  There is likely future work
> to be done here...

Well, while I agree that there is a choice to be made of whether to return an answer or a referral I will have to say that I think that choice belongs in the authoritative end, not in the recursor.

> On Sat, Jan 17, 2015 at 10:08:48PM +0000, Viktor Dukhovni wrote:
> 
>> Also, how would one configure unbound to use an auto-trust-anchor-file
>> via RFC 5011 for a given gTLD or ccTLD?
> 
> Any comment on my second question?  If one enables RFC 5011 tracking
> for all the trust anchors one cares about, it is no longer necessary
> to worry about delegation-only above those trust anchors.

Not necessary for whom to worry? For the admin of that particular instance of a recursive server or for the owner of some zone the structure of which is suddenly not quite under their control because someone somewhere said that zone FOO should be delegation-only.

All of DNS is based on a few fundamental principles, one of which is that the structure of the namespace is decided in the authoritative part. Incidentally, discussing this with various ISC folks over the years it is clear that they agree and that the delegation-only option is just plain wrong. The only reason that this piece of wrong ever made it into BIND9 was as a defense against the Verisign lets-put-a-wildcard-in-com-and-net party trick many years ago. 

The problem with putting something wrong into BIND9, even if it was for a good cause, is that it gets used by vast numbers of people and then it can never ever be taken out again.

So here we are, almost ten years down the line, no wildcards in .COM or .NET (or elsewhere that matters) but were stuck with the delegation-only option in BIND9 forever. To add the same wrongness into Unbound at this point seems to me to be a really... avoidable mistake.

Regards,

Johan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20150119/cfa951b1/attachment.bin>