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.
This feature is of course not urgent, it would be more useful if
for various TLDs (and not just the root) it were feasible to "pin"
the DNSKEY RRs via RFC 5011, and/or "transparency" of some kind
were implemented for DNSSEC.
Still I think it would be useful to consider whether and when to
include such a feature. I may of course not have thought this
through properly, ...
Also, how would one configure unbound to use an auto-trust-anchor-file
via RFC 5011 for a given gTLD or ccTLD?
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.
> 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".
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...
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.
>>
>> 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.
I don't think turning on root-delegation-only has been recommended by the
ISC for years.
Yes of course, that makes sense. We're may not be quite there yet.
And yet at some point this may become more important, and so the
question is whether unbound is ready to support such non-root zones
if when they show up...
I can, for example, envision the ".de" TLD adopting such a policy,
and interested resolvers starting to track those keys per RC 5011,
thereby closing opportunities for the root zone keys to return
improper .de answers.
Also, how would one configure unbound to use an
auto-trust-anchor-file via RFC 5011 for a given gTLD or
ccTLD?
$ dig mytld DNSKEY > mytld.key
# check if key is trustworthy
# add a line to unbound.conf:
auto-trust-anchor-file: "mytld.key"
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.
I don't know of any zones other than the root which promise to
follow the RFC 5011 key rollover timing requirements. (And even
the root zone does it wrong by not having a standby KSK.)
If you want to use RFC 5011 on a TLD you will have to inspect
their DNSSEC Practice Statement with care.
Yes of course, that makes sense. We're may not be quite there
yet. And yet at some point this may become more important, and so
the question is whether unbound is ready to support such non-root
zones if when they show up...
You can add them into the config file with the auto-trust-anchor-file
statement. You can repeat this statement in the config file to add
more trust anchors.
I can, for example, envision the ".de" TLD adopting such a policy,
and interested resolvers starting to track those keys per RC 5011,
thereby closing opportunities for the root zone keys to return
improper .de answers.
If you have nested trust anchors, unbound uses the closest one by
preference (i.e. exactly what you say that you want).
> 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?
A zone did not delegate its name servers. If you queried for their
addresses using a regular client, subsequent cache misses from the
zone would result in error responses because BIND could not find any
valid name servers anymore.
There's also the question of further protocol development which might
introduce additional authoritative records such as DNSKEY (but IIRC,
BIND only applies the filter to A/AAAA queries).