Re: [dns-operations] any registries require DNSKEY not DS?

[Olafur Gudmundsson]

> On Apr 17, 2020, at 4:45 PM, Brian Dickson  
> wrote:
> 
> 
> 
> On Fri, Apr 17, 2020 at 12:57 PM Olafur Gudmundsson  > wrote:
> 
> 
>> On Jan 22, 2020, at 11:16 PM, Paul Vixie > > wrote:
>> 
>> On Thursday, 23 January 2020 02:51:28 UTC Warren Kumari wrote:
>>> ...
>>> 
>>> If the parent makes the DS for me from my DNSKEY, well, then the DS
>>> suddently "feels" like it belongs more to the parent than the child,
>>> but this is starting to get into the "I no longer know why I believe
>>> what I believe" territory (and is internally inconsistent), so I'll
>>> just stop thinking about this and go shopping instead :-)
>> 
>> as you see, the DS RRset is authoritative in the parent, in spite of its 
>> name 
>> being the delegation point, which is otherwise authoritative only in the 
>> child. so, DS really is "owned by" the delegating zone, unlike, say, NS.
>> 
>> historians please note: we should have put the DS RRset at $child._dnssec.
>> $parent, so that there was no exception to the rule whereby the delegation 
>> point belongs to the child. this was an unforced error; we were just 
>> careless. 
>> so, example._dnssec.com  rather than example.com 
>> .
>> 
>> -- 
>> Paul
>> 
> 
> Paul, 
> If start talking about history and looking back with hindsight 
> 
> IMHO the second biggest mistake in DNS design was to have the same type in 
> both parent and child zone 
> If RFC1035 had specified DEL record in parent and NS in child or the other 
> way around it would have been obvious to 
> specify a range of records that were parent only (just like meta records)  
> thus all resolvers from the get go would have known that types in that range 
> only reside at the parent.
> …… 
> If we had the DEL record then that could also have provided the glue hints 
> and no need for additional processing, 
> 
> Would the method have potentially been to have GLUEA and GLUE records 
> rather than effectively overloading the A/ status (authoritative vs not)?
> And then all of the new types that live only in the parent, could have been 
> signed.
> I'm guessing it's way to late to start doing that now, without rev'ing all of 
> DNS to v2.
> 
> 

Assuming that GLUEx records were Parent side only that is possible, but I was 
thinking that DEL could be like a TXT 
foo.  DEL   "ns1.foo”  “127.0.0.1”  “1::dead:beef”   
and this would have been what was used to do the initial lookup into child 
zone. 
Yes this all will require DNSng and that is a ……. 


> Brian
> 
>  
> 
> You may recall that in 1995 when you and I were trying to formalize for 
> DNSSEC what the the exact semantics of NS record were, then you and Paul 
> Mockapetris came up with 
> “Parent is authoritative for the existence of NS record, Child is 
> authoritative for the contents” 
> 
> 
> Just in case you are wondering what was the biggest mistake that is QR bit, 
> recursion should have been on a different port than Authoritative.
> 
> But this is all hindsight based on 30 years of coding and operational 
> difficulties.
> 
> Regards, 
> Ólafur
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net 
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations 
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net 
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations 
> 
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Paul Vixie]

On Friday, 17 April 2020 19:48:48 UTC Olafur Gudmundsson wrote:
> > On Jan 22, 2020, at 11:16 PM, Paul Vixie  wrote:
> > 
> > ...
> > 
> > historians please note: we should have put the DS RRset at $child._dnssec.
> > $parent, so that there was no exception to the rule whereby the delegation
> > point belongs to the child. this was an unforced error; we were just
> > careless. so, example._dnssec.com rather than example.com.
> 
> Paul,
> If start talking about history and looking back with hindsight
> 
> IMHO the second biggest mistake in DNS design was to have the same type in
> both parent and child zone If RFC1035 had specified DEL record in parent
> and NS in child or the other way around it would have been obvious to
> specify a range of records that were parent only (just like meta records) 
> thus all resolvers from the get go would have known that types in that
> range only reside at the parent. ……
> If we had the DEL record then that could also have provided the glue hints
> and no need for additional processing,
> 
> You may recall that in 1995 when you and I were trying to formalize for
> DNSSEC what the the exact semantics of NS record were, then you and Paul
> Mockapetris came up with “Parent is authoritative for the existence of NS
> record, Child is authoritative for the contents”
> 
> Just in case you are wondering what was the biggest mistake that is QR bit,
> recursion should have been on a different port than Authoritative.
> 
> But this is all hindsight based on 30 years of coding and operational
> difficulties.
> 
> Regards,
> Ólafur

other than that i think you meant the RD bit, and that you're reminding me 
(indirectly) of all the times i should have been smarter or more polite or 
both, i am +1 to your comments above.

-- 
Paul



___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Mark Andrews]

> On 18 Apr 2020, at 08:00, Viktor Dukhovni  wrote:
> 
> On Fri, Apr 17, 2020 at 01:45:02PM -0700, Brian Dickson wrote:
> 
>> Would the method have potentially been to have GLUEA and GLUE
>> records rather than effectively overloading the A/ status
>> (authoritative vs not)?
>> 
>> And then all of the new types that live only in the parent, could have
>> been signed.
> 
> Probably something like that, or perhaps still with host names.
> 
>> I'm guessing it's way to late to start doing that now, without rev'ing
>> all of DNS to v2.
> 
> Well it need not be a flag day, provided the parent zone is still
> willing to publish legacy unsigned glue along with the new signed
> delegation records, newer clients would prefer the new records and
> older clients would use the legacy glue.
> 
> Support for the new delegation records can be signalled via a
> (new) bit in the parent zone DNSKEY flags.  This would avoid
> having to pay the cost of asking for them in zones that don't
> yet support the new signed delegation RRs.
> 
> These would also reduce opportunities for DoS via the IP
> fragmentation attacks, ... because delegation records would
> no longer be subject to forgery.

Or the TLD operators could turn off IPv4 and go IPv6 only with
non counter fragmentation ID generation enabled.  That would
stop fragmentation reassembly attempts succeeding.  I’m not
sure of the state of play with id generation on Linux boxes but
BSD boxes can definitely meet the criteria.

Or we could adopt the well known TSIG approach and defeat
fragmentation attacks that way.  This works for both IPv4 and IPv6.

> The key question is whether parent zone operators (e.g. TLDs)
> can be convinced that this is a good idea.  They would now
> need to sign all the delegations, not just the secure ones,
> so the immediate audience for this would be the TLDs where
> say ~25% or more of the delegations are already signed:
> 
>.nl, .se, .cz, .br, ...
> 
> and signing everything would not be a dramatic new cost.
> 
> --
>Viktor.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Viktor Dukhovni]

On Fri, Apr 17, 2020 at 01:45:02PM -0700, Brian Dickson wrote:

> Would the method have potentially been to have GLUEA and GLUE
> records rather than effectively overloading the A/ status
> (authoritative vs not)?
>
> And then all of the new types that live only in the parent, could have
> been signed.

Probably something like that, or perhaps still with host names.

> I'm guessing it's way to late to start doing that now, without rev'ing
> all of DNS to v2.

Well it need not be a flag day, provided the parent zone is still
willing to publish legacy unsigned glue along with the new signed
delegation records, newer clients would prefer the new records and
older clients would use the legacy glue.

Support for the new delegation records can be signalled via a
(new) bit in the parent zone DNSKEY flags.  This would avoid
having to pay the cost of asking for them in zones that don't
yet support the new signed delegation RRs.

These would also reduce opportunities for DoS via the IP
fragmentation attacks, ... because delegation records would
no longer be subject to forgery.

The key question is whether parent zone operators (e.g. TLDs)
can be convinced that this is a good idea.  They would now
need to sign all the delegations, not just the secure ones,
so the immediate audience for this would be the TLDs where
say ~25% or more of the delegations are already signed:

.nl, .se, .cz, .br, ...

and signing everything would not be a dramatic new cost.

--
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Brian Dickson]

On Fri, Apr 17, 2020 at 12:57 PM Olafur Gudmundsson  wrote:

>
>
> On Jan 22, 2020, at 11:16 PM, Paul Vixie  wrote:
>
> On Thursday, 23 January 2020 02:51:28 UTC Warren Kumari wrote:
>
> ...
>
> If the parent makes the DS for me from my DNSKEY, well, then the DS
> suddently "feels" like it belongs more to the parent than the child,
> but this is starting to get into the "I no longer know why I believe
> what I believe" territory (and is internally inconsistent), so I'll
> just stop thinking about this and go shopping instead :-)
>
>
> as you see, the DS RRset is authoritative in the parent, in spite of its
> name
> being the delegation point, which is otherwise authoritative only in the
> child. so, DS really is "owned by" the delegating zone, unlike, say, NS.
>
> historians please note: we should have put the DS RRset at $child._dnssec.
> $parent, so that there was no exception to the rule whereby the delegation
> point belongs to the child. this was an unforced error; we were just
> careless.
> so, example._dnssec.com rather than example.com.
>
> --
> Paul
>
>
> Paul,
> If start talking about history and looking back with hindsight
>
> IMHO the second biggest mistake in DNS design was to have the same type in
> both parent and child zone
> If RFC1035 had specified DEL record in parent and NS in child or the other
> way around it would have been obvious to
> specify a range of records that were parent only (just like meta records)
>  thus all resolvers from the get go would have known that types in that
> range only reside at the parent.
> ……
> If we had the DEL record then that could also have provided the glue hints
> and no need for additional processing,
>

Would the method have potentially been to have GLUEA and GLUE records
rather than effectively overloading the A/ status (authoritative vs
not)?
And then all of the new types that live only in the parent, could have been
signed.
I'm guessing it's way to late to start doing that now, without rev'ing all
of DNS to v2.

Brian



>
> You may recall that in 1995 when you and I were trying to formalize for
> DNSSEC what the the exact semantics of NS record were, then you and Paul
> Mockapetris came up with
> “Parent is authoritative for the existence of NS record, Child is
> authoritative for the contents”
>
>
> Just in case you are wondering what was the biggest mistake that is QR
> bit, recursion should have been on a different port than Authoritative.
>
> But this is all hindsight based on 30 years of coding and operational
> difficulties.
>
> Regards,
> Ólafur
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Olafur Gudmundsson]

> On Jan 22, 2020, at 11:16 PM, Paul Vixie  wrote:
> 
> On Thursday, 23 January 2020 02:51:28 UTC Warren Kumari wrote:
>> ...
>> 
>> If the parent makes the DS for me from my DNSKEY, well, then the DS
>> suddently "feels" like it belongs more to the parent than the child,
>> but this is starting to get into the "I no longer know why I believe
>> what I believe" territory (and is internally inconsistent), so I'll
>> just stop thinking about this and go shopping instead :-)
> 
> as you see, the DS RRset is authoritative in the parent, in spite of its name 
> being the delegation point, which is otherwise authoritative only in the 
> child. so, DS really is "owned by" the delegating zone, unlike, say, NS.
> 
> historians please note: we should have put the DS RRset at $child._dnssec.
> $parent, so that there was no exception to the rule whereby the delegation 
> point belongs to the child. this was an unforced error; we were just 
> careless. 
> so, example._dnssec.com rather than example.com.
> 
> -- 
> Paul
> 

Paul, 
If start talking about history and looking back with hindsight 

IMHO the second biggest mistake in DNS design was to have the same type in both 
parent and child zone 
If RFC1035 had specified DEL record in parent and NS in child or the other way 
around it would have been obvious to 
specify a range of records that were parent only (just like meta records)  thus 
all resolvers from the get go would have known that types in that range only 
reside at the parent.
…… 
If we had the DEL record then that could also have provided the glue hints and 
no need for additional processing, 

You may recall that in 1995 when you and I were trying to formalize for DNSSEC 
what the the exact semantics of NS record were, then you and Paul Mockapetris 
came up with 
“Parent is authoritative for the existence of NS record, Child is authoritative 
for the contents” 


Just in case you are wondering what was the biggest mistake that is QR bit, 
recursion should have been on a different port than Authoritative.

But this is all hindsight based on 30 years of coding and operational 
difficulties.

Regards, 
Ólafur

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Andrew Sullivan]

On Thu, Jan 23, 2020 at 05:28:15PM -0500, Warren Kumari wrote:
> That's fair - but that's more of a (good) argument for the parent
> calculating the DS from the DNSKEY

I always believed that this was the only defensible thing, given that
DS is authoritative at the parent.  I was in the rough.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Maarten Bosteels]

On Wed, Jan 22, 2020 at 11:51 PM Patrick Mevzek 
wrote:

> On 22/01/2020 17:13, Tony Finch wrote:
> > Are there any registries that configure secure delegations from DNSKEY
> > records (and do their own conversion to DS records) rather than accepting
> > DS records from the registrant? I think I have heard that .de is one.
>
> CA (IIRC they require both the key and DS, probably to double check the
> DS themselves), BE and EU are some example that comes immediately to
> mind. There are others.
>
>
Indeed, for .be we expect the registrar to send us the DNSKEY using
a  element (when using EPP)
https://docs.dnsbelgium.be/be/epp/createdomain.html

Maarten Bosteels
DNS Belgium
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Warren Kumari]

On Thu, Jan 23, 2020 at 3:39 PM Florian Weimer  wrote:
>
> * Warren Kumari:
>
> > On Wed, Jan 22, 2020 at 9:19 PM Viktor Dukhovni 
wrote:
> >>
> >> On Wed, Jan 22, 2020 at 10:13:40PM +, Tony Finch wrote:
> >>
> >> > Are there any registries that configure secure delegations from
DNSKEY
> >> > records (and do their own conversion to DS records) rather than
accepting
> >> > DS records from the registrant?
> >>
> >> In answer to the converse question, at least some registries appear to
> >> allow (or have allowed in the past) DS RRs with unverified content:
> >
> >
> > This actually seems OK to me -- nonsensical, but OK.
>
> It makes attacks on the underlying hash function for the DS record
> easier.  Constructing colliding prefixes is much harder if the prefix
> itself contains the hash over something else (because you also have to
> construct that something).

That's fair - but that's more of a (good) argument for the parent
calculating the DS from the DNSKEY than not allowing children to put in
things like unregistered algorithm/ hash types.  We’ve had lots of
deployment issues with things like restrictive registrar web interfaces
that don’t allow users to enter valid DS records because they haven’t been
updated yet; there is a trade off between protecting users from themselves,
and agility...

W





-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Maarten Bosteels]

On Wed, Jan 22, 2020 at 11:51 PM Patrick Mevzek 
wrote:

>
> CA (IIRC they require both the key and DS, probably to double check the
> DS themselves), BE and EU are some example that comes immediately to
> mind. There are others.
>
>
Indeed, for .be we expect the registrar to send us the  DNSKEY using
a  element
See for example https://docs.dnsbelgium.be/be/epp/createdomain.html

Maarten Bosteels
DNS Belgium
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Viktor Dukhovni]

On Thu, Jan 23, 2020 at 09:38:00PM +0100, Florian Weimer wrote:

> >> In answer to the converse question, at least some registries appear to
> >> allow (or have allowed in the past) DS RRs with unverified content:
> >
> > This actually seems OK to me -- nonsensical, but OK.
> 
> It makes attacks on the underlying hash function for the DS record
> easier.  Constructing colliding prefixes is much harder if the prefix
> itself contains the hash over something else (because you also have to
> construct that something).

Yes, if at some future time (not expected any time soon) practical
chosen-prefix collision attacks are discovered against SHA2-256, they
would be rather difficult to mount against a parent zone when the DS RR
payload is computed from the DNSKEY by the registrey.

This is not presently the primary reason to validate parameters,
generally the reason to do that is to keep the namespace largely free of
obvious breakage, reducing support costs, improving the image of the
TLD, and promoting adoption of DNSSEC best-practices.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Florian Weimer]

* Warren Kumari:

> On Wed, Jan 22, 2020 at 9:19 PM Viktor Dukhovni  
> wrote:
>>
>> On Wed, Jan 22, 2020 at 10:13:40PM +, Tony Finch wrote:
>>
>> > Are there any registries that configure secure delegations from DNSKEY
>> > records (and do their own conversion to DS records) rather than accepting
>> > DS records from the registrant?
>>
>> In answer to the converse question, at least some registries appear to
>> allow (or have allowed in the past) DS RRs with unverified content:
>
>
> This actually seems OK to me -- nonsensical, but OK.

It makes attacks on the underlying hash function for the DS record
easier.  Constructing colliding prefixes is much harder if the prefix
itself contains the hash over something else (because you also have to
construct that something).
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Frederico A C Neves]

On Wed, Jan 22, 2020 at 09:06:21PM -0500, Viktor Dukhovni wrote:
> On Wed, Jan 22, 2020 at 10:13:40PM +, Tony Finch wrote:
> 
> > Are there any registries that configure secure delegations from DNSKEY
> > records (and do their own conversion to DS records) rather than accepting
> > DS records from the registrant?
> 
> In answer to the converse question, at least some registries appear to
> allow (or have allowed in the past) DS RRs with unverified content:
> 
> domain   | alg | digest type
> -+-+
> .go.leg.br  |   8 |0
> .go.leg.br  |   8 |1
> .pr.leg.br |   8 |0
> .sp.leg.br   |   8 |0

Just as a matter of clarification, those fourth level "grandchild"
delegations are beyond the registry control. The third level ones are
totally correct.

Fred
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Tony Finch]

Thanks for all the interesting replies!

The reason for the question is to do with child-side tools for updating
delegations. RFC 7344 CDS/CDNSKEY records are brilliant for this because
they provide a standard interface between key management / signing
software and registr* API client software: the registr* client can
just [*] look at a zone file to work out what the delegation should be.
And clearly a generic "gimme the secure delegation" function needs to have
both DS and DNSKEY modes.

[*] modulo caveats about glue records

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
the quest for freedom and justice can never end
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Tony Finch]

Viktor Dukhovni  wrote:
>
> Which is not to say that one should continue to use SHA-1 in DS RRs,
> there but there is little risk in doing for the foreseable future.

Right. Getting rid of SHA-1 in DS and CDS might not be cryptographically
necessary [*], but it's required for protocol conformance, and it's
important to actually make visible progress to deprecating SHA-1 even if
we start with the easy but less important steps.

[*] Registries that don't check DS parameters, like the examples you gave,
are vulnerable so chosen prefix collisions if they are relaxed enough to
allow 800-ish bytes of digest...

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shannon: Variable 4 or less, becoming south or southwest 4 to 6. Moderate,
becoming rough in northwest. Mainly fair. Good.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[John W. O'Brien]

On 2020/01/22 17:13, Tony Finch wrote:
> Are there any registries that configure secure delegations from DNSKEY
> records (and do their own conversion to DS records) rather than accepting
> DS records from the registrant? I think I have heard that .de is one.
> Looking at OpenSRS as an example of a registrar that supports lots of
> TLDs, I see that they don't support DNSSEC for .de
> http://opensrs.help/chart and their API only supports DS records
> https://domains.opensrs.guide/docs/set_dnssec_info
> 
> Also, I am uncomfortable with the endianness of their support domain names...
> 
> Tony.
> 

I'm not sure whether any *registries* require DNSKEY vs DS, but I am
familiar with differences among *registrars* via direct and recent (on
the order of hours and days) experience with updating DS records for
COM, NET, ORG, ARPA, and EDU.

COM via GKG: DS
NET via GKG: DS
NET via gandi: DNSKEY
ORG via GKG: DS
ORG via gandi: DNSKEY
ARPA via ARIN: DS
EDU via EDUCAUSE: DS

The only evidence I observed/recall that a registrar attempted to
validate the supplied parameters is that GKG warned upon submission
before accepting and allowed override.

-- 
John W. O'Brien
OpenPGP keys:
0x33C4D64B895DBF3B



signature.asc
Description: OpenPGP digital signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Marc Groeneweg via dns-operations]

--- Begin Message ---
All,

Yes, SIDN is still using DNSKEY for reasons stated by Antoin in the past. 

Regards,
Marc

On Wed, Jan 22, 2020 at 5:26 PM Tony Finch  wrote:
>
> Are there any registries that configure secure delegations from DNSKEY
> records (and do their own conversion to DS records) rather than accepting
> DS records from the registrant?

I believe that at least SIDN used to (and perhaps still does) - this
was one of the reasons that the CDS record is actually CDS/CDNSKEY.

When I first heard this I was confused as to why they'd do this -- but
then Antoin Verschuren / Cristian explained that they'd like to make
sure that a good hash is being used, and suddenly I started wondering
why this isn't the default...:-)

I *think* that someone from .ca (perhaps Jacques or Matt) said that
they also allow DNSKEYs -- but this is all from 2014 timetrams, and my
memory is (sadly) paging that out...
W

> I think I have heard that .de is one.
> Looking at OpenSRS as an example of a registrar that supports lots of
> TLDs, I see that they don't support DNSSEC for .de
> http://opensrs.help/chart and their API only supports DS records
> https://domains.opensrs.guide/docs/set_dnssec_info
>
> Also, I am uncomfortable with the endianness of their support domain 
names...
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> responsible stewardship of the earth and its resources
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations



smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Paul Vixie]

On Thursday, 23 January 2020 02:51:28 UTC Warren Kumari wrote:
> ...
> 
> If the parent makes the DS for me from my DNSKEY, well, then the DS
> suddently "feels" like it belongs more to the parent than the child,
> but this is starting to get into the "I no longer know why I believe
> what I believe" territory (and is internally inconsistent), so I'll
> just stop thinking about this and go shopping instead :-)

as you see, the DS RRset is authoritative in the parent, in spite of its name 
being the delegation point, which is otherwise authoritative only in the 
child. so, DS really is "owned by" the delegating zone, unlike, say, NS.

historians please note: we should have put the DS RRset at $child._dnssec.
$parent, so that there was no exception to the rule whereby the delegation 
point belongs to the child. this was an unforced error; we were just careless. 
so, example._dnssec.com rather than example.com.

-- 
Paul


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Warren Kumari]

On Wed, Jan 22, 2020 at 9:19 PM Viktor Dukhovni  wrote:
>
> On Wed, Jan 22, 2020 at 10:13:40PM +, Tony Finch wrote:
>
> > Are there any registries that configure secure delegations from DNSKEY
> > records (and do their own conversion to DS records) rather than accepting
> > DS records from the registrant?
>
> In answer to the converse question, at least some registries appear to
> allow (or have allowed in the past) DS RRs with unverified content:


This actually seems OK to me -- nonsensical, but OK. The DS record
"belongs" to the child, and so I feel like, as long as it isn't
harmful to the parent / the Internet, the child can put whatever
silliness in there that they would like.
If I chose to hand my parent an NS record with 192.168.0.22 as the
address, I'd expect them to publish it -- I understand (and
appreciate) that some ccTLDs perform sanity checks, and have various
policies they they will only accept "good" data, but that's an
explicit choice by them - absent such a policy, I think I should be
able to add a DS with algorithm 42, digest type of 17, and rdata of
badc0ffee.

If the parent makes the DS for me from my DNSKEY, well, then the DS
suddently "feels" like it belongs more to the parent than the child,
but this is starting to get into the "I no longer know why I believe
what I believe" territory (and is internally inconsistent), so I'll
just stop thinking about this and go shopping instead :-)


W

>
> domain   | alg | digest type
> -+-+
> .go.leg.br  |   8 |0
> .go.leg.br  |   8 |1
> .pr.leg.br |   8 |0
> .sp.leg.br   |   8 |0
> .se   |  13 |8
> .se|   8 |   61
>
> The above 5 (obfuscated) domains have DS RRs with digest types outside
> the registered IANA codepoints:
>
> https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
>
> though the first also has a valid codepoint.
>
> Among domains with at least one valid DNSKEY at least two have
> additional keys with out of range codepoints, that were either not
> checked by the parent, or added after the initial DS enrolment:
>
>   domain| alg | flags | inception
> +-+---+
> .eu  | 157 | 0 | 
> .eu  |   7 |   256 |  -"-
> .eu  |   7 |   257 |  -"-
> .net |   7 |   256 |  -"-
> .net |   7 |   257 |  -"-
> .net | 165 |   512 | 2019-02-23
>
> --
> Viktor.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Viktor Dukhovni]

On Thu, Jan 23, 2020 at 12:12:15AM +, Tony Finch wrote:

> By default dnssec-cds copies CDS records to make DS records, and the
> question of SHA-256 or something else only arose when it was asked to turn
> CDNSKEY records into DS records. But if the CDS records are generated by
> some ancient code from before the dawn of time, such as BIND 9.14 on my
> production servers, there will be SHA-1 CDS records which will be copied
> to the DS records. Sadface, RFC 8624 protocol violation.

But SHA-1 is still quite safe as a DS digest type, the problematic use
is SHA-1 RRSIGs.  In the context of DS RRs, only 2nd-preimage attacks
matter, and the prospect of those *even against MD5* is still remote.

Which is not to say that one should continue to use SHA-1 in DS RRs,
there but there is little risk in doing for the foreseable future.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Viktor Dukhovni]

On Wed, Jan 22, 2020 at 10:13:40PM +, Tony Finch wrote:

> Are there any registries that configure secure delegations from DNSKEY
> records (and do their own conversion to DS records) rather than accepting
> DS records from the registrant?

In answer to the converse question, at least some registries appear to
allow (or have allowed in the past) DS RRs with unverified content:

domain   | alg | digest type
-+-+
.go.leg.br  |   8 |0
.go.leg.br  |   8 |1
.pr.leg.br |   8 |0
.sp.leg.br   |   8 |0
.se   |  13 |8
.se|   8 |   61

The above 5 (obfuscated) domains have DS RRs with digest types outside
the registered IANA codepoints:

https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

though the first also has a valid codepoint.

Among domains with at least one valid DNSKEY at least two have
additional keys with out of range codepoints, that were either not
checked by the parent, or added after the initial DS enrolment:

  domain| alg | flags | inception
+-+---+
.eu  | 157 | 0 | 
.eu  |   7 |   256 |  -"-
.eu  |   7 |   257 |  -"-
.net |   7 |   256 |  -"-
.net |   7 |   257 |  -"-
.net | 165 |   512 | 2019-02-23

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Warren Kumari]

On Wed, Jan 22, 2020 at 7:12 PM Tony Finch  wrote:
>
> Warren Kumari  wrote:
> >
> > I believe that at least SIDN used to (and perhaps still does) - this
> > was one of the reasons that the CDS record is actually CDS/CDNSKEY.
> >
> > When I first heard this I was confused as to why they'd do this -- but
> > then Antoin Verschuren / Cristian explained that they'd like to make
> > sure that a good hash is being used, and suddenly I started wondering
> > why this isn't the default...:-)
>
> In fact I have made use of this! In more than one way!
>
> I did some work on BIND last year to implement RFC 8624 section 3.3 -
> death to SHA-1 DS records! But I left out the dnssec-cds utility
> (parent-side implementation of RFC 7344) which already defaulted to
> SHA-256. However during my cam.ac.uk algorithm rollover project
> (remember, folks, RSASHA1 is shafted) I found a lacuna:
>
> By default dnssec-cds copies CDS records to make DS records, and the
> question of SHA-256 or something else only arose when it was asked to turn
> CDNSKEY records into DS records. But if the CDS records are generated by
> some ancient code from before the dawn of time, such as BIND 9.14 on my
> production servers, there will be SHA-1 CDS records which will be copied
> to the DS records. Sadface, RFC 8624 protocol violation.
>
> So I fixed dnssec-cds to filter out SHA-1 CDS records.
>
> And, if the child turns out to have been so foolish as to use only SHA-1,
> dnssec-cds will now fall back to using the CDNSKEY records to make SHA-256
> DS records instead.
>

Oooh! Cool.


> In production for my child zones I've faked this by telling dnssec-cds
> (9.14 sans patch) to only look at CDNSKEY records.
>
> All in all this is a practical example of daddy knows best wrt choice of
> DS digest types.
>

Nice / fair 'nuff.
W

> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Faeroes: Southwest 6 to gale 8, veering west 7 to severe gale 9. Very rough or
> high. Rain then wintry showers. Good, occasionally poor.



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Tony Finch]

Warren Kumari  wrote:
>
> I believe that at least SIDN used to (and perhaps still does) - this
> was one of the reasons that the CDS record is actually CDS/CDNSKEY.
>
> When I first heard this I was confused as to why they'd do this -- but
> then Antoin Verschuren / Cristian explained that they'd like to make
> sure that a good hash is being used, and suddenly I started wondering
> why this isn't the default...:-)

In fact I have made use of this! In more than one way!

I did some work on BIND last year to implement RFC 8624 section 3.3 -
death to SHA-1 DS records! But I left out the dnssec-cds utility
(parent-side implementation of RFC 7344) which already defaulted to
SHA-256. However during my cam.ac.uk algorithm rollover project
(remember, folks, RSASHA1 is shafted) I found a lacuna:

By default dnssec-cds copies CDS records to make DS records, and the
question of SHA-256 or something else only arose when it was asked to turn
CDNSKEY records into DS records. But if the CDS records are generated by
some ancient code from before the dawn of time, such as BIND 9.14 on my
production servers, there will be SHA-1 CDS records which will be copied
to the DS records. Sadface, RFC 8624 protocol violation.

So I fixed dnssec-cds to filter out SHA-1 CDS records.

And, if the child turns out to have been so foolish as to use only SHA-1,
dnssec-cds will now fall back to using the CDNSKEY records to make SHA-256
DS records instead.

In production for my child zones I've faked this by telling dnssec-cds
(9.14 sans patch) to only look at CDNSKEY records.

All in all this is a practical example of daddy knows best wrt choice of
DS digest types.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Faeroes: Southwest 6 to gale 8, veering west 7 to severe gale 9. Very rough or
high. Rain then wintry showers. Good, occasionally poor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Patrick Mevzek]

On 22/01/2020 17:53, Warren Kumari wrote:
> When I first heard this I was confused as to why they'd do this -- but
> then Antoin Verschuren / Cristian explained that they'd like to make
> sure that a good hash is being used, and suddenly I started wondering
> why this isn't the default...:-)

The IANA TLD template for changes, even if done through a website now
and not by email, asks for the DS, not the DNSKEY:

https://www.iana.org/domains/root/tld-change-template.txt

One data point merely on this question about which case is right or not.
The EPP secDNS option allows both, in fact three: DS, DNSKEY, or DNSKEY+DS

On a non technical level it is more about who really controls the DS
record at parent. If a child want suddenly to try new things, or new
algorithms come and stuff like that, if you have to send the DNSKEY to
the parent then you are limited by what choices the parent give to you
and you may not be able to have the specific DS you would like. Some
will prefer to have safeguards ("parent should make sure child does not
shoots itself in the foot"), others will prefer to be "agile" and have
full liberty (and hence full power to shoots itself in the foot).

Registrants have exact same problem when they want their registrar just
to forward their desired DS record to registry, irrespective to what the
registrar knows and does about DNSSEC. Some will prefer to have a
specific UI that validates everything before sending to registry (which
can make sense in case the registry gives the registrar penalties for
faulty commands), and hence loosing some liberty, and others will prefer
to have the registrar just send the string as an opaque blob and let end
registrant deal with problems.

It also depends what a "good hash" is. If it is just filtering on the
key algorithm/key digest type, those information are in the data send by
registrar to registry, so the DS record is enough for this check.

If the registry wants to do DNSSEC checks completely it would have to do
live DNS queries at the child anyway to see what it really publishes as
DNSKEY not what it says - through EPP - that it would publish.

It is the same problem as doing DNS delegation validation at the moment
you want to change nameservers (to check new ones are properly
configured) vs doing them "randomly" during the life of a domain (or at
least not just once at delegation time but after also).

-- 
Patrick Mevzek
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Rubens Kuhl]

Not exactly what you asked, but a registrar example: Openprovider requires 
registrant to provide the DNSKEY, not DS, to activate and manage DNSSEC.


Rubens

> On 22 Jan 2020, at 19:13, Tony Finch  wrote:
> 
> Are there any registries that configure secure delegations from DNSKEY
> records (and do their own conversion to DS records) rather than accepting
> DS records from the registrant? I think I have heard that .de is one.
> Looking at OpenSRS as an example of a registrar that supports lots of
> TLDs, I see that they don't support DNSSEC for .de
> http://opensrs.help/chart and their API only supports DS records
> https://domains.opensrs.guide/docs/set_dnssec_info
> 
> Also, I am uncomfortable with the endianness of their support domain names...
> 
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> responsible stewardship of the earth and its resources
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Sergey Myasoedov]

I think .ru/.рф were requiring DNSKEY together with DS to publish the DS. Or 
maybe the registrars were performing additional checks if the DS correspond to 
DNSKEY.


--
Sergey

> On 22 Jan 2020, at 23:13, Tony Finch  wrote:
> 
> Are there any registries that configure secure delegations from DNSKEY
> records (and do their own conversion to DS records) rather than accepting
> DS records from the registrant? I think I have heard that .de is one.
> Looking at OpenSRS as an example of a registrar that supports lots of
> TLDs, I see that they don't support DNSSEC for .de
> http://opensrs.help/chart and their API only supports DS records
> https://domains.opensrs.guide/docs/set_dnssec_info
> 
> Also, I am uncomfortable with the endianness of their support domain names...
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> responsible stewardship of the earth and its resources
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Peter Koch]

On Wed, Jan 22, 2020 at 10:13:40PM +, Tony Finch wrote:
> Are there any registries that configure secure delegations from DNSKEY
> records (and do their own conversion to DS records) rather than accepting
> DS records from the registrant? I think I have heard that .de is one.

this is correct. There were/are at least two more, but I'd let them respond.

-Peter
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] any registries require DNSKEY not DS?

[Warren Kumari]

On Wed, Jan 22, 2020 at 5:26 PM Tony Finch  wrote:
>
> Are there any registries that configure secure delegations from DNSKEY
> records (and do their own conversion to DS records) rather than accepting
> DS records from the registrant?

I believe that at least SIDN used to (and perhaps still does) - this
was one of the reasons that the CDS record is actually CDS/CDNSKEY.

When I first heard this I was confused as to why they'd do this -- but
then Antoin Verschuren / Cristian explained that they'd like to make
sure that a good hash is being used, and suddenly I started wondering
why this isn't the default...:-)

I *think* that someone from .ca (perhaps Jacques or Matt) said that
they also allow DNSKEYs -- but this is all from 2014 timetrams, and my
memory is (sadly) paging that out...
W

> I think I have heard that .de is one.
> Looking at OpenSRS as an example of a registrar that supports lots of
> TLDs, I see that they don't support DNSSEC for .de
> http://opensrs.help/chart and their API only supports DS records
> https://domains.opensrs.guide/docs/set_dnssec_info
>
> Also, I am uncomfortable with the endianness of their support domain names...
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> responsible stewardship of the earth and its resources
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations