[DNSOP] RFC 8145 on Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 8145

Title:  Signaling Trust Anchor Knowledge in 
DNS Security Extensions (DNSSEC) 
Author: D. Wessels, W. Kumari, P. Hoffman
Status: Standards Track
Stream: IETF
Date:   April 2017
Mailbox:dwess...@verisign.com, 
war...@kumari.net, 
paul.hoff...@icann.org
Pages:  13
Characters: 27110
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-dnsop-edns-key-tag-05.txt

URL:https://www.rfc-editor.org/info/rfc8145

DOI:10.17487/RFC8145

The DNS Security Extensions (DNSSEC) were developed to provide origin
authentication and integrity protection for DNS data by using digital
signatures.  These digital signatures can be verified by building a
chain of trust starting from a trust anchor and proceeding down to a
particular node in the DNS.  This document specifies two different
ways for validating resolvers to signal to a server which keys are
referenced in their chain of trust.  The data from such signaling
allow zone administrators to monitor the progress of rollovers in a
DNSSEC-signed zone.

This document is a product of the Domain Name System Operations Working Group 
of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-01.txt

[Matthew Pounsett]

On 11 April 2017 at 15:27, Carl Clements  wrote:

>
> There is one detail that I feel is not explicit enough in 6781 that is
> extremely relevant during a DNSSEC operator migration. It is assumed in
> this document that DNSKEY_*_A and DNSKEY_*_B use the same signature
> algorithm. That assumption is derived from the implication that this
> document describes a Double-DS KSK rollover, which is incompatible with
> an algorithm rollover even with the liberal approach to Section 2.2 of
> RFC 4035 . I think it
> would be helpful to at least reference this implication in section 2.1 of
> your draft.
>

This is an excellent point, and I'll add that to the doc ... likely in the
assumptions for now.  More below.


>
> My other thought is regarding the instruction to pre-publish DNSKEY_K_B
> and post publish DNSKEY_K_A. As far as I can tell, and we have discussed
> this a little out of band, the only value provided by publishing and
> signing this KSK is to satisfy any over-conservative DS checks performed by
> the maintainers of the parent zone. The essential chain of trust "cross
> pollination" is that both DNSKEY_Z_A and DNSKEY_Z_B are signed by the
> either KSK.
>

Yeah, the procedure as described in the doc currently is a little
over-cautious with key handling.  It's mainly to simplify the description
of requirements, but I'm planning to change the way it's written out.

One piece of feedback I've received privately is that the document could
benefit from having the *requirements* for a clean transfer spelled out,
and that the procedure be included as an example, possibly of the shortest
path to meet the requirements.  I think that bit of reorganization would
help with the explanation of when it's actually important to
pre/post-publish keys, and coincidentally provide a good place for your
note about algo compatibility to live.

I've been working on text, but it's been a busy few months so I'm not quite
ready to roll -03.


> Lastly, it looks as though you opted to spell out TTL waits, for example.
> For what is it worth, I am in favour of this choice.
>
> I added that in -02 with the long-form description of the procedure.
Given that the intended audience is not intended to be able to work out
this procedure on their own, I thought it was important to be as explicit
as possible.

Thanks for the feedback!
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Evan Hunt]

On Tue, Apr 11, 2017 at 10:20:31PM +0200, Florian Weimer wrote:
> And in order to accommodate them, we upgrade the DNS server 
> infrastructure across the Internet?

Them, and web browser implementers who just don't want to use SRV.

We did the best we could to ensure it can be deployed gradually,
though. The domain that wants to redirect apex addresses can implement
ANAME, and its clients will get answers. Resolvers that want better
answers can do that too. Forklift not required.

> I understand that's how things work in practice, but I don't like it.

So say we all.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Florian Weimer]

On 04/11/2017 10:16 PM, Evan Hunt wrote:

On Tue, Apr 11, 2017 at 09:11:54PM +0200, Florian Weimer wrote:

I don't see how you can detect loops without DNS protocol changes.  The
query that comes back will look like a completely fresh query.


We can put a limit on the number of hops that are followed in populating
the A and  records for the expanded ANAME response.  If that limit is
exceeded, the ANAME record could be rejected by the auth; either the zone
wouldn't load or address queries return SERVFAIL.


But what happens when the target server also performs cache filling at 
the same time?


Thanks,
Florian

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Evan Hunt]

On Tue, Apr 11, 2017 at 10:21:13PM +0200, Florian Weimer wrote:
> But what happens when the target server also performs cache filling at 
> the same time?

If two servers end up being unable to populate their address records
because they're depending on each other for answers, then you end up
with two servers that both return SERVFAIL on address queries.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Florian Weimer]

On 04/11/2017 10:15 PM, Tony Finch wrote:



On 11 Apr 2017, at 20:39, Florian Weimer  wrote:

On 04/11/2017 09:15 PM, Tony Finch wrote:

That doesn't work if the web server is at 3rd party provider A but you want 
provider B's mail service not provider A's.


I don't understand.

I think it boils down to who operates the target DNS zone and how flexible they 
are.  It has nothing to do with who runs the web server.


In many cases the ANAME target will be a mass web hosting provider which 
doesn't have any flexibility in their DNS setup.


And in order to accommodate them, we upgrade the DNS server 
infrastructure across the Internet?


I understand that's how things work in practice, but I don't kike it.


And you still don't want CNAME pointing at MX because of the interop problems.


CNAME to MX is fine.  Isn't this what's relevant here?

Thanks,
Florian

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Evan Hunt]

On Tue, Apr 11, 2017 at 09:11:54PM +0200, Florian Weimer wrote:
> I don't see how you can detect loops without DNS protocol changes.  The 
> query that comes back will look like a completely fresh query.

We can put a limit on the number of hops that are followed in populating
the A and  records for the expanded ANAME response.  If that limit is
exceeded, the ANAME record could be rejected by the auth; either the zone
wouldn't load or address queries return SERVFAIL.

BIND already has a limit of 16 hops for CNAME loop prevention. I assume
other resolver implementations must do something similar.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Florian Weimer]

On 04/11/2017 09:15 PM, Tony Finch wrote:



On 11 Apr 2017, at 20:09, Florian Weimer  wrote:


On 04/11/2017 08:42 PM, Tony Finch wrote:

If you have a subdomain that needs to be a mail domain and a web site, you
need an MX pointing at your mail server and address records pointing at
your web server. You can't use a CNAME because they are usually different
servers.


That's not a problem, you can have MX records at the CNAME target.


That doesn't work if the web server is at 3rd party provider A but you want 
provider B's mail service not provider A's.


I don't understand.

I think it boils down to who operates the target DNS zone and how 
flexible they are.  It has nothing to do with who runs the web server.


Thanks,
Florian

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Florian Weimer]

On 04/10/2017 12:04 PM, Peter van Dijk wrote:


Section 3 is currently written in such a way that a recursive DNS
lookup must be performed at the authoritative server side.  I don't
think it is necessary to require that.  A recursive DNS lookup of the
target is just one way to implement this.


What other ways did you have in mind?


Private arrangement with the target zone operator (that is, direct, out 
of-band access to the zone).



In particular, the suggested recursive DNS lookup needs some form of
distributed loop detection.  Otherwise, a malicious customer could
publish two zones with ANAME records and achieve significant traffic
amplification, potentially taking down the DNS hoster.  A hop count in
an EDNS option or an “ANAME lookup in progress” indicator would be one
way to implement this.  Another approach would impose restrictions on
the owner name of an ANAME record and its target, and restrict where
CNAMEs can appear, so that a valid ANAME can never point to another
valid ANAME.


I’m not sure it’s feasible to forbid chaining ANAMEs. I do agree there
is a vector for DoS here. Section 6 currently cowardly says “Both
authoritative servers and resolvers that implement ANAME should
carefully check for loops and treat them as an error condition.” but I
am aware that more words are needed.


I don't see how you can detect loops without DNS protocol changes.  The 
query that comes back will look like a completely fresh query.


Thanks,
Florian

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Tony Finch]

> On 11 Apr 2017, at 20:09, Florian Weimer  wrote:
> 
>> On 04/11/2017 08:42 PM, Tony Finch wrote:
>> 
>> If you have a subdomain that needs to be a mail domain and a web site, you
>> need an MX pointing at your mail server and address records pointing at
>> your web server. You can't use a CNAME because they are usually different
>> servers.
> 
> That's not a problem, you can have MX records at the CNAME target.

That doesn't work if the web server is at 3rd party provider A but you want 
provider B's mail service not provider A's.

You might also have NAPTR records pointing at providers C and D.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Florian Weimer]

On 04/11/2017 08:42 PM, Tony Finch wrote:

Paul Wouters  wrote:


Can you give me an example of deploying ANAME outside the zone APEX that
is not solved by allowing a CNAME to point to a CNAME (which most code I
think already allows anyway)


https://www.ietf.org/mail-archive/web/dnsop/current/msg19909.html

If you have a subdomain that needs to be a mail domain and a web site, you
need an MX pointing at your mail server and address records pointing at
your web server. You can't use a CNAME because they are usually different
servers.


That's not a problem, you can have MX records at the CNAME target.


Also, mail domains cannot in practice be CNAMEs because of the disaster of
RFC 821 / RFC 1122 mail domain canonicalization.


I can see why this is a concern, but does current sendmail still rewrite 
the headers?  (The envelope recipient is far less problematic.)


Thanks,
Florian

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Florian Weimer]

On 04/11/2017 05:45 PM, Tony Finch wrote:

Florian Weimer  wrote:


I think the introduction should discuss why it is not possible to push the
CNAME to the parent zone, replacing the entire zone with an alias.


You can't replace an entire zone with a CNAME if it has subdomains. ANAME
records are not just for zone apexes. There are lots of other cases where
address records need a different alias target from MX records, or NAPTR
records, etc.


Sure, but the document should list that.

FWIW, I think the real problem is that it is perceived as cheaper to 
upgrade DNS servers than to support CNAME records in the provisioning 
infrastructure.


Thanks,
Florian

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Tony Finch]

Paul Wouters  wrote:
>
> Can you give me an example of deploying ANAME outside the zone APEX that
> is not solved by allowing a CNAME to point to a CNAME (which most code I
> think already allows anyway)

https://www.ietf.org/mail-archive/web/dnsop/current/msg19909.html

If you have a subdomain that needs to be a mail domain and a web site, you
need an MX pointing at your mail server and address records pointing at
your web server. You can't use a CNAME because they are usually different
servers.

Also, mail domains cannot in practice be CNAMEs because of the disaster of
RFC 821 / RFC 1122 mail domain canonicalization.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Fitzroy: Easterly or northeasterly 4 or 5, occasionally 6 in south. Slight or
moderate, occasionally rough at first in south. Fair. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Paul Wouters]

On Tue, 11 Apr 2017, Tony Finch wrote:


ANAME
records are not just for zone apexes. There are lots of other cases where
address records need a different alias target from MX records, or NAPTR
records, etc.


Can you give me an example of deploying ANAME outside the zone APEX that
is not solved by allowing a CNAME to point to a CNAME (which most code I
think already allows anyway)

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Tony Finch]

Evan Hunt  wrote:
>
> Expansion of ANAME on the authoritative end is a workaround for the
> fact that we can't go back in time and put ANAME support into all
> the resolvers.

On the authoritative side I think server behaviour should be partitioned
into primary and secondary:

Primary servers are able to modify zone contents. This might be old skool
batch provisioning or dynamic on-demand trickery.

Secondary servers just serve what they get via xfer from primaries.

ANAME expansion happens on primaries and (in the future) on recursors, but
not secondaries nor stubs.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Easterly or southeasterly 4 or 5, but 6 or 7 in far southeast,
becoming variable 4 later except far southeast. Slight or moderate. Fair.
Moderate or good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Tony Finch]

Florian Weimer  wrote:
>
> I think the introduction should discuss why it is not possible to push the
> CNAME to the parent zone, replacing the entire zone with an alias.

You can't replace an entire zone with a CNAME if it has subdomains. ANAME
records are not just for zone apexes. There are lots of other cases where
address records need a different alias target from MX records, or NAPTR
records, etc.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Forties, Cromarty: West 5 to 7, perhaps gale 8 later. Moderate or rough. Rain
then showers. Good occasionally poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Peter van Dijk]

Hello Jan,

On 10 Apr 2017, at 16:16, Jan Včelák wrote:

> On Fri, Apr 7, 2017 at 8:11 PM, Evan Hunt wrote:
>> Here's the new ANAME draft I mentioned last week.
>
> Besides that, The Security Section should warn DNS operators that
> ANAME may be misused to leak data from any internal networks the
> server is part of. This was so far concern for resolvers, but with
> ANAME it may become a concern for authoritative servers as well.

Oh good catch, thanks!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop