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

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

[Tony Finch]

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

Re: [dns-operations] DNS of Turk Telekom

[Marc Groeneweg via dns-operations]

--- Begin Message ---
Nope. The information is sparse. But I guess something like BGP is involved!?

Anyone has more detailed concrete information about this "DNS attack"?


https://www.itnews.com.au/news/turk-telekom-says-internet-access-restored-after-cyber-attack-536767
___
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] EDNS Client Subnet (ECS) in queries sent to Google Public DNS

[Alexander Dupuy via dns-operations]

--- Begin Message ---
Florian Weimer writes:
> How would a DoH client know that the recursive resolver is "forbidden
> to forward" ECS data?

Dave Lawrence replies:

> It doesn't know clearly.  All it knows is that if it gets REFUSED when
> it sends a prefix outside its own address space, then something was
> wrong.  If that then succeeds it can only be inferred that the
> specified network was the problem.

It’s a bit worse than that, since there is no 100% reliable way to
distinguish whether REFUSED indicates a problem with the ECS address data
or a queried domain name for which ECS is blocked (or both). However, since
the action taken in any of these cases is the same (resend without ECS),
it’s not necessary for the client to be able to distinguish them, although
it would be useful to be able to do so to determine whether to cache the
response as a global answer valid for any address.

Ralph Dolmans writes:

> Unbound will query again without ECS when receiving a REFUSED.

I’m glad to hear that, and hope that other forwarding resolvers do the
same. However, I expect there are many that do not. As far as Unbound’s
behavior, how does it cache the response that it gets from a non-ECS retry?
Are they cached for the client address at some default (/24 or /56) scope?
Or are they cached as untargeted responses that could be used instead of
making a non-ECS retry (but would not prevent an initial query with ECS)?
Or just not cached at all?

> Is there a reason these will only be REFUSED when
> using DoT/DoH? I think you never want to return a /0 scope in this case,
> as that makes it possible for an user to trigger an answer that will be
> cached and used for all addresses, assuming the forwarder will also
> forward non-routable ECS source addresses.

It’s a question of trade-offs. DoH/DoT queries are still a relatively green
field; there are fewer DoH/DoT clients (and even fewer that send ECS), and
they are more likely to retry without ECS when they get a REFUSED. This
reduces the negative impact of REFUSED responses for clients that do not
retry without ECS.

There is another possibility besides a /0 scope response (current behavior)
and returning REFUSED, which is to send a response without ECS at all.
However, clients may interpret that as a lack of support for ECS, which
might prevent them from sending zero-length address ECS to stop a recursive
from sending their actual IP subnet to authoritative name servers. Since
clients may cache a non-ECS response to an ECS query as a global response
suitable for all addresses, omitting ECS might be no better than returning
a /0 scope. For those reasons, retaining the current behavior for cleartext
queries seems the best choice.

In the long term, ECS would only be supported for encrypted transports, to
preserve client privacy as much as possible while still giving accurate
geo-targeted results. The Mozilla TRR policy
 privacy requirement
6 is a first step in this direction, if perhaps somewhat premature, since
there is still no standard mechanism for DoT to authoritative, and even
opportunistic DoT is only possible for one authoritative server operator.
As ECS is still sent in cleartext to authoritative servers, requiring that
it be encrypted from a client may seem pointless, but there is some privacy
benefit to encrypting ECS at any point, even if it is not encrypted
end-to-end. For now, it seemed appropriate to at least require that clients
not be sending cleartext ECS address data with longer prefixes than
recommended by RFCs, that would not be used by Google Public DNS.

@alex


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