In message <f322b183-de6a-4173-9de6-afc1f1417...@fl1ger.de>, Ralf Weber writes:
> Moin!
>
> On 21 May 2014, at 16:16, Mark Andrews <ma...@isc.org> wrote:
> > More that it was assumed that people would read the rfc and enforce
> > the prohibition themselves. When that wasn't happening it was first
> > made into a warning '97 and fatal in '99.
>
> IMHO a software should not allow me to make incorrect entries. I think
> having the assumption that everybody editing a zone file would have read
> the RFCs is a bit far fetched.
Well if you want to complain about software that was fixed 15 years ago.
Additionally sometimes the software can't determine if something
is wrong or not.
foo_bar.example.net CNAME foo-bar.example.com
foo-bar.example.com A 1.2.3.4
foo-bar.example.com TXT some text
does not make foo_bar.example.net a legal host name. Some things do
need to be left to the zone adminstrators to do the correct thing.
> > No, it will not break DNSSEC resolvers. If you were to need to
> > use ENAME and you are signing then only validators that were aware
> > of ENAME would mark you as secure. The existing validators would
> > treat you as insecure. If you don't need the ENAME functionality
> > you would continue to use the existing algorithms when signing.
>
> We have different definition of breaking. To me when a validator gives me
> an insecure on something that has DNSSEC signatures and proper secure
> delegation I consider that broken as it probably allows neat downgrade
> attacks.
DNSSEC has *never* been "has signatures, will be treated as secure".
You needed a chain of trust and common sets of algorithms for every
zone in that chain.
> > Introducing NSEC3 did not break existing validators. Introducing
> > ENAME will not break existing validators.
>
> NSEC3 was defined before the root was signed, so there was no real
> deployment. Now we have granted limited, but deployment on the
> authoritative as well as resolver/validator side. So we have to be much
> more careful on the impact of what we do to people who do the right thing
> (validating) now.
When the root was signed there were still lots of NSEC only validators
in use.
And given almost all infrastructure zones don't allow anything other
than delegations this will have no impact on them. Nobody will be
forcing them to use the new algorithms to sign their zones until
they add a ENAME record. That is the forcing operation on the
signer.
Today you can't tell a signer to generate NSEC3 chains if there are
any non-NSEC3 capable DNSKEYs in the zone. You won't be able to add
ENAME records to a zone without all ENAME capable DNSKEYs.
Use of ENAME in infrastructure zones.
5 years after the publication of this rfc (<Month> <Year>) it will
be assumed that validators support ENAME. Prior to this date
it is NOT RECOMMENDED that infrastructure zones be signed using
ENAME aware algorithms or use ENAME if they were signed using non
ENAME aware algorithms at the time of publication. Additionally
after this date unless you intend to add ENAME records it is NOT
RECOMMENDED that ENAME aware algorithms be used in infrastructure
zones without further advice to the contrary.
This is intended to minimise the number of zones that will be go
from being treated as secure to insecure due to the use of ENAME
in a infrastructure zone.
> So long
> -Ralf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
