Subject: Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Aug 2014 10:16:09 +1000

Can we please move on this.

	The reverse address are not yet insecurely delegated as
	would be required for RFC 6598 compliance.  This is starting
	to cause operational problems for ISP's that validate DNS
	responses as they can't deploy local IN-ADDR.ARPA zones
	until that insecure delegation is done.

	Also should I add a reminder to the IANA Considerations that
	the insecure delegation needs to be performed?

	e.g.

	"IANA is reminded that a insecure delegation for these zones
	is required for compliance with RFC 6598 to break the DNSSEC
	chain of trust."

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Wed, 13 Aug 2014 20:57:46 -0400 (EDT)

Hi

I have read through this and would support its progress.  A reminder for 
the record would not be a bad idea I think.

On Thu, 14 Aug 2014, Mark Andrews wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

wfms

---

From: Dick Franks <[email-masked]>
Date: Thu, 14 Aug 2014 14:11:38 +0100

Mark,

Surely, something stronger than a reminder is appropriate.

For a mission-critical requirement, this needs to be an explicit and
unambiguous request:

    "This document directs IANA to create insecure delegations
     for the listed zones."

Dick
________________________

---

From: Joe Abley <[email-masked]>
Date: Thu, 14 Aug 2014 10:40:29 -0400

> 	is required for compliance with RFC 6598 to break the DNSSEC

I'm confused. We're talking about 100.64.0.0/10, I think. The only delegation under IANA's control is 100.in-addr.arpa to nameservers operated by ARIN, which is (and should be, I think) a secure delegation. What are you asking IANA to do? Make a request of ARIN? Something else?

More generally, if you are asking the chairs to facilitate the process of adoption of this draft by the dnsop wg, it might be as well to say so clearly (it's not obvious from your message above).

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 Aug 2014 02:04:52 +1000

> > 	would be required for RFC 6598 compliance.  This is starting

		correction RFC 6303

> I'm confused. We're talking about 100.64.0.0/10, I think. The only
> delegation under IANA's control is 100.in-addr.arpa to nameservers
> operated by ARIN, which is (and should be, I think) a secure delegation.
> What are you asking IANA to do? Make a request of ARIN? Something else?

The assignements go:

	0.0.0.0/0 IANA		(IN-ADDR.ARPA)
	100.0.0.0/8 ARIN	(100.IN-ADDR.ARPA)
	100.64.0.0/10 IANA	(64.100.IN-ADDR.ARPA through
				 127.100.IN-ADDR.ARPA)

The 100.64/10 address range is assigned to IANA.  IANA has not yet
setup IN-ADDR.ARPA zones and servers for this range.  IANA needs
to tell ARIN to delegate them to somewhere insecurely.  A logical
place to delegate them to is the same servers that serve 100.IN-ADDR.ARPA
if ARIN is will to set up the zones on them otherwise IANA will
need to find a different set of servers to delegate to.  In either
case this will change the answer returned from a secure NXDOMAIN
from 100.IN-ADDR.ARPA to a insecure NXDOMAIN from 64.100.IN-ADDR.ARPA
for the reverse of 100.64.x.y.  Repeat for the other 63 zones in
the range.

This will break the DNSSEC chain of trust the same way as the
insecure delegation of 10.IN-ADDR.ARPA and the rest of the RFC 1918
reverse zones to the AS112 servers does.

RFC 6598 effectively says answer these locally with "don't forward
to the global internet".  This cannot currently be done if you are
validating answers as the only answer that will validate is a
NXDOMAIN response from 100.IN-ADDR.ARPA.  Once the insecure delegation
is in place these queries can be answered locally because the
validator will be told securely that there isn't a DS for
64.100.IN-ADDR.ARPA through 127.100.IN-ADDR.ARPA.

> More generally, if you are asking the chairs to facilitate the process of
> adoption of this draft by the dnsop wg, it might be as well to say so
> clearly (it's not obvious from your message above).

The draft is adopted. Went to last call then stalled. drc started
worrying about if there were other registries to be updated.

---

From: Joe Abley <[email-masked]>
Date: Thu, 14 Aug 2014 12:19:51 -0400

On 14 Aug 2014, at 12:04, Mark Andrews <[email-masked]> wrote:

> setup IN-ADDR.ARPA zones and servers for this range.

Since there is no secure delegation in place right now, anybody who wants to set up their own reverse DNS (and e.g. point their resolvers at it through resolver configuration) can do so, right? So there's no current problem?

Are you reacting to some other suggestion that one or both of ARIN and IANA are keen to insert a secure delegation for each of those 64 zones?

It seems to me that no delegation is a perfectly reasonable steady state, so long as ARIN doesn't mind the NXDOMAIN load from leaked queries. An alternative to a delegation (if they do care) would be a DNAME redirection to EMPTY.AS112.ARPA once that is available.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 Aug 2014 09:36:27 +1000

In message <[email-masked]>, Joe Abley writes:
> Since there is no secure delegation in place right now, anybody who wants
> to set up their own reverse DNS (and e.g. point their resolvers at it
> through resolver configuration) can do so, right? So there's no current
> problem?

The last delegation in the current chain is a secure delegation from
IN-ADDR.ARPA to 100.IN-ADDR.ARPA so there is a problem currently.
No one can safely setup their own reverse zones validation is now
starting to be done in stub resolvers and to do so would result in
validation failures.

> Are you reacting to some other suggestion that one or both of ARIN and
> IANA are keen to insert a secure delegation for each of those 64 zones?

I'm saying that there needs to be a delegation and that the delegation
needs to be insecure.  There currently isn't a delegation at this level.

> It seems to me that no delegation is a perfectly reasonable steady state,
> so long as ARIN doesn't mind the NXDOMAIN load from leaked queries. An
> alternative to a delegation (if they do care) would be a DNAME
> redirection to EMPTY.AS112.ARPA once that is available.

Given that IN-ADDR.ARPA -> 100.IN-ADDR.ARPA is a secure delegation
there is currently no way to safely intercept the queries.  I also
don't think that ISP's that deploy 100.64/10 should be unable to
safely add reverse zones for that range.

---

From: Chris Thompson <[email-masked]>
Date: 20 Aug 2014 17:24:00 +0100

On Aug 15 2014, Mark Andrews wrote:

[...]
>needs to be insecure.  There currently isn't a delegation at this level.

This thread reminds me that the same problem arises if one wants to
locally define reverse zones for the IPv4 multicast addresses described
in sections 6.1 and 6.2 of RFC 2365, i.e. parts of 239.192.0.0/10.
239.in-addr.arpa is signed with a chain of trust from the root, but
it doesn't contain any sort of delegation for these address ranges.

What would be the right way to officially request IANA to do for
239.192.0.0/10 what Mark Andrews is proposing for 100.64.0,0/10?
At least in this case ARIN is not involved: 239.in-addr.arpa is
all IANA's own work!

-- 
Chris Thompson               University of Cambridge Information Services,
Email: [email-masked]    Roger Needham Building, 7 JJ Thomson Avenue,
Phone: +44 1223 334715       Cambridge CB3 0RB, United Kingdom.

---

From: Chris Thompson <[email-masked]>
Date: 20 Aug 2014 17:50:02 +0100

On Aug 14 2014, Joe Abley wrote:

[...]
>It seems to me that no delegation is a perfectly reasonable steady state,

It fails to break the chain of trust. Because a validator can "prove" that
the names in the putative subzone do not exist, it will consider locally
defined content "bogus". The only way around this is either to have all
local nameservers be authoritative for the subzone (e.g. by slaving it)
or to sign it and have them all configured with a trust anchor. (Negative
trust anchors would make this a bit easier, but as we know a certain
common nameserver implementation does not support them...)

Depending on how large "local" is this can be difficult to achieve, and
in the particular use case of 100.64.0.0/10 it is liable to be big.

>alternative to a delegation (if they do care) would be a DNAME redirection
>to EMPTY.AS112.ARPA once that is available.

Would this last actually work to break the chain of trust (provided that
EMPTY.AS112.NET was itself unsigned)? I am having difficulty working out
exactly what a validator would do in this situation.

---

From: Joe Abley <[email-masked]>
Date: Wed, 20 Aug 2014 15:28:07 -0400

Hi Chris,

I went quiet on this thread because I was going to try this out in a lab before commenting further, but since I haven't done that and you had something to say...

On 20 Aug 2014, at 12:50, Chris Thompson <[email-masked]> wrote:

> defined content "bogus".

Doesn't this depend on how you do it?

(a) If your resolvers are all configured as authoritative for the zones that you want special treatment for (e.g. 239.in-addr.arpa, 64.100.in-addr.arpa) I think the expected behaviour is that they will return that authoritative data in response to queries.

So, for example, if your BIND9 recursive server has a bunch of "type master" or "type slave" zones, stub resolvers will get answers regardless of the presence or absence of RRSIGs, secure delegations elsewhere, etc.

(b) If your resolvers are configured with those special zones as "forward" type zones (again, using BIND9 language) and the local authoritative servers for those zones are separate, is the behaviour different? I had thought it was the same as (a).

(c) If you are providing service for particular zones locally by hijacking the traffic intended for the real servers out on the Internet, then it does seem likely that your answers are going to be ignored as bogus by a validator.

Since (c) is about the hardest and most unsupportable way of doing this, I hadn't thought it much of a problem (the mitigation is "well, don't do it like that"). Am I wrong about (a) and (b)?

Joe

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2014 07:48:45 +1000

In message <[email-masked]>, Joe Abley writes
:
> Hi Chris,
>
> I went quiet on this thread because I was going to try this out in a lab
> before commenting further, but since I haven't done that and you had
> something to say...
>
> (a) If your resolvers are all configured as authoritative for the zones
> that you want special treatment for (e.g. 239.in-addr.arpa,
> 64.100.in-addr.arpa) I think the expected behaviour is that they will
> return that authoritative data in response to queries.
>
> So, for example, if your BIND9 recursive server has a bunch of "type
> master" or "type slave" zones, stub resolvers will get answers regardless
> of the presence or absence of RRSIGs, secure delegations elsewhere, etc.

You will give answers that validate as bogus in the stub resolver.
A validating stub resolver talking to a ISP's recursive server will
reject the answers from the ISP's server.

> (b) If your resolvers are configured with those special zones as
> "forward" type zones (again, using BIND9 language) and the local
> authoritative servers for those zones are separate, is the behaviour
> different? I had thought it was the same as (a).

The answers received from the forwarder will be rejected as bogus.

> (c) If you are providing service for particular zones locally by
> hijacking the traffic intended for the real servers out on the Internet,
> then it does seem likely that your answers are going to be ignored as
> bogus by a validator.
>
> Since (c) is about the hardest and most unsupportable way of doing this,
> I hadn't thought it much of a problem (the mitigation is "well, don't do
> it like that"). Am I wrong about (a) and (b)?

All down stream validating clients will reject the answers as the reverse
namespace for 100.64/10 is currently configured.  All the above senarios
lead to the answers being rejected.

---

From: Joe Abley <[email-masked]>
Date: Wed, 20 Aug 2014 19:29:12 -0400

> You will give answers that validate as bogus in the stub resolver.

This seems to be the crux of our differing world views.

> A validating stub resolver

Validating stub resolvers?

In my own personal taxonomy a stub resolver doesn't validate. Validation signalling is available from a validating resolver (e.g. using the AD bit, of which I am not a fan), and that resolver (validating or not) is where I was suggesting the locally-relevant data would be served.

(Note that I'm not saying that my own personal taxonomy is of any use to anybody apart from me; I'm just putting it out there by way of explanation of the current forehead wrinkles. I continue to think it would be good to have a common understanding of these overloaded terms.)

Anyway, I'm not arguing against the idea of making certain delegations verifiably insecure. I think any of us could write up an I-D with an IANA Considerations section that specified the correct behaviour, if we want to do this properly with a documentation trail. (Maybe the nice IANA DNS Operations people could be convinced to make the change anyway without or in advance of documentation, but I tend to think that documentation is good in general.)

Joe

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2014 09:51:18 +1000

In message <[email-masked]>, Joe Abley writes
:
> In my own personal taxonomy a stub resolver doesn't validate. Validation
> signalling is available from a validating resolver (e.g. using the AD
> bit, of which I am not a fan), and that resolver (validating or not) is
> where I was suggesting the locally-relevant data would be served.
>
> (Note that I'm not saying that my own personal taxonomy is of any use to
> anybody apart from me; I'm just putting it out there by way of
> explanation of the current forehead wrinkles. I continue to think it
> would be good to have a common understanding of these overloaded terms.)
>
> Anyway, I'm not arguing against the idea of making certain delegations
> verifiably insecure. I think any of us could write up an I-D with an IANA
> Considerations section that specified the correct behaviour, if we want
> to do this properly with a documentation trail. (Maybe the nice IANA DNS
> Operations people could be convinced to make the change anyway without or
> in advance of documentation, but I tend to think that documentation is
> good in general.)

IANA should have enough from RFC6598 as it says that lookups shouldn't
go to the Internet and they only way for that to work with validating
resolvers is to break the DNSSEC chain of trust.  It is a implict
instuction but it is a instruction.

Or we could finish !@$!#$!@#@R!EW!RQ@ processing this document and
IANA will follow the explict instructions in RFC6303.  It has passed
wg last call on January 3rd, 2014 and stalled!

I don't see any Q@#R#!@##$ point in writing a third document.

Yes, I'm !@#RQWRET!$#R!@# annoyed.

"On Dec 7, 2013, at 5:59 AM, Tim Wicinski <tim.wicinski at teamaol.com> wrote:
We're kicking off the Working Group Last call on Adding 100.64.0.0/10 prefixes to IPv4 Locally-Served DNS Zones Registry. The author believe that this document has addressed all the issues raised on the document.  The latest version of the draft is available at:

    http://www.ietf.org/id/draft-ietf-dnsop-rfc6598-rfc6303-00.txt
    http://tools.ietf.org/html/draft-ietf-dnsop-rfc6598-rfc6303-00

Because of this last call is surrounded by the upcoming holiday season, we're making this a four (4) week last call cycle. 
Substantive comments and statements of support/opposition for advancing this document should be directed to the mailing list. Editorial
suggestions can be sent directly to the authors. The chairs will send in their comments as well during the last call period. This last call will
conclude on January 3rd, 2014."

I had a previous document stall for *years* after last call passed
with dnsop as Peter just didn't do the writeup.  I don't wan't the
same thing to happening for this document as well.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2014 10:52:46 +1000

> > would be good to have a common understanding of these overloaded terms.)

DNSSEC responses were, from day one, designed to be validated in
the application/client/resolver library.  For the discussion about
100.64/10 reverse in which of these places is immaterial

Getting validation into recursive servers was a first step and it
also protected non-DNSSEC aware clients from a class of attacks.
It was also one of the easiest piece to update which was why it was
promoted first.  It was also a required step as you can't reliably
validate in the client unless the recursive server has filtered out
the spoofed answers.

The next step was/is getting validation performed in the clients.
There are several validating stub resolver libraries from different
vendors.  ISC has shipped one as part of BIND for over a decade.

Yes, you can link libdns into a application and have it validate
answers you receive from a recursive server before handing them to
the application.  named is the main application that uses this
library but it is not the only one.  The newer releases have simpler
calling points and setup.

Validation is starting to move into the application with inititatives
like DANE.

AD is only useful as a signal that a answer is secure when you can
trust the path between the recursive server and the application
*and* you can trust the configuration of the recursive server to
be setting AD appropriately.  See all the caveats about trusting
AD in the RFC's where it is mentioned.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Aug 2014 21:21:00 -0400

On Thu, Aug 21, 2014 at 10:52:46AM +1000, Mark Andrews wrote:
> It was also a required step as you can't reliably

If I understand you correctly, this devolves to the claim that the
validating client has to do its own recursion, lest it trut something
without basis.  Is that what you're suggesting?  I'm not opposed, but
let us be clear.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Aug 2014 21:27:56 -0400

> without basis.  Is that what you're suggesting?  I'm not opposed, but

I will confess to being deeply puzzled by this conversation, which probably means that I've missed something.   What Mark appears to be saying above is that if a recursive server has been given bogus answers to feed to the stub, and the stub tries to validate them, the validation will fail.   This is mom and apple pie.   The cure for this is not for the stub to do its own recursion, if by that you mean it should bypass the caching resolver.   The cure is not to send it stuff that won't validate.

The only way to do this is to make delegations for these zones that are insecure, as is proposed in the document.   I do not understand how this can be controversial, and Joe's explanation didn't help me.  Of course we should assume that stubs validate, even if that is not the current state of the art.

What am I missing?

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Aug 2014 18:51:58 -0700

Hi,

> without basis.  Is that what you're suggesting?  I'm not opposed, but

I’m getting confused.

What’s the difference between the “validating client” and a full validating resolver?  Just the lack of cache?

Tanks,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2014 12:02:44 +1000

> without basis.  Is that what you're suggesting?  I'm not opposed, but

Even, if you 100% trust the recursive server, DNSSEC will not
reliably work through a recursive server unless that server filters
spoofed answers as a stub resolver, by definition, doesn't directly
query the authoritative sources.  You get filtered answers by sending
CD=0 queries to a validating recursive server.

This is why "always send CD=1" is bad.  The validating application
/ stub resolver needs to get answers that have been filtered.  It
can then reject spoofed last mile responses to its queries to the
recursive server.  When the last mile is from 8.8.8.8 and similar
this is important.

Yes, this does mean that validation is done in two places on good
answers.

Even if you don't trust the recursive server you can still use it
as you will validate the answers you get.  Spoofed answers from
secure zones for which you have a trust chain for will not get
though.

If the recursive server does not validate, then as long as the
recursive server sets DO=1 on its queries and is not under attack,
the stub resolver will still get the data required to validate the
answers and it will almost always succeed.  This is equivalent to
always sending CD=1 requests to a validating recursive resolver as
it then works in pass through mode when it doesn't have the answer
already cached.
 
Now if you are getting bogus answers from all the recursive servers,
you can fallback to making direct iterative queries.  This may or
may not succeed depending upon what the actual issue for the failure
is.  If you are getting SERVFAIL you can try flipping CD state on
your queries before falling back to interative queries.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2014 12:17:25 +1000

In message <[email-masked]>, David Conrad writes:
> I'm getting confused.
> What's the difference between the "validating client" and a full
> validating resolver?  Just the lack of cache?
>
> Tanks,
> -drc

A validating application (client it too overloaded) will use a stub
resolver, which set DO=1 and CD=0 (yes, this is not what the RFC
6840 says) on the applications behalf, to get answers from a caching
recursive server, which it will then validate.  If the validation
fails it can try any other recursive servers.  If they fail it can
fallback to making iterative queries or just accept the failure.
The recovery will be more easily done if it is built into the
resolver library as it knows which recursive servers it has queried.
It should also retry the queries in case there were spoofed responses.

The basic difference is where it directs its queries to.  Whether
there is or isn't a cache is a implementation detail.

Mark

---

From: Evan Hunt <[email-masked]>
Date: Thu, 21 Aug 2014 03:28:48 +0000

On Thu, Aug 21, 2014 at 12:17:25PM +1000, Mark Andrews wrote:
> If they fail it can

I'd quibble with this bit: if it can make iterative queries, then we
might as well just call it a validating resolver.

IMHO the thing we're describing is an application that gets DNS service
from a recursive resolver, but validates the answers rather than trusting
them implicitly.  It needs to be able to send the resolver a succession of
queries to obtain the chain of trust, but it's not going to be iterating
down from the root.

The "delv" utility that ships with BIND 9.10 is an example.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2014 13:23:58 +1000

In message <[email-masked]>, Chris Thompson w
> At least in this case ARIN is not involved: 239.in-addr.arpa is

Write up a draft for this range requesting that the DNSSEC chain
of trust gets broken for reverse range as per the method described
in RFC 6303.