Subject: [dnsoverhttp] New draft: draft-hoffman-dns-over-http-00.txt

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Sep 2016 14:54:30 +0000

Greetings. As Joe and I presaged on the list last week, here is our draft on the HTTP parts of DNS over HTTP. We tried to cover all of the issues that any foo-over-HTTP document should cover, and to be sure that every normal DNS query (even with extensions) could be specified. If we missed any, we're happy to update.

--Paul Hoffman

> A new version of I-D, draft-hoffman-dns-over-http-00.txt
> has been successfully submitted by Paul Hoffman and posted to the
> IETF repository.
> 
> Name:		draft-hoffman-dns-over-http
> Revision:	00
> Title:		DNS Queries over HTTPS
> Document date:	2016-09-20
> Group:		Individual Submission
> Pages:		12
> URL:            https://www.ietf.org/internet-drafts/draft-hoffman-dns-over-http-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hoffman-dns-over-http/
> Htmlized:       https://tools.ietf.org/html/draft-hoffman-dns-over-http-00
> 
> 
> Abstract:
>   This document describes how to make DNS queries and get DNS responses
>   over HTTPS.  The main driver for this document is to allow clients
>   who want to send DNS queries over HTTP transport to be able to do in
>   a secure and interoperable fashion, regardless of the format of the
>   responses.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Sep 2016 13:40:12 -0700

Hi Paul, Joe,

Thanks for the draft.  Reading through it, it seems to posit a mechanism
for providing a DNS API server that will serve the same function as a
recursive resolver would now.  Given that this is basically similar to a
recursive resolver putting up a new API, I'm not sure why the complication
of a non-standardized prefix is the right trade-off.  Why not standardize
it?  If not standardized, why not use the well known URI mechanisms?

I also note that this seems to be answering a different use case than
Patrick and Martin were talking about in regards to server push.  With
this, server push might be used for something like additional data, but you
wouldn't see this in the same context as "normal" HTTPS connections, so
server push from a content server wouldn't apply. Have I got that bit right?

regards,

Ted

On Tue, Sep 20, 2016 at 7:54 AM, Paul Hoffman <[email-masked]>
wrote:

> Greetings. As Joe and I presaged on the list last week, here is our draft
> on the HTTP parts of DNS over HTTP. We tried to cover all of the issues
> that any foo-over-HTTP document should cover, and to be sure that every
> normal DNS query (even with extensions) could be specified. If we missed
> any, we're happy to update.
>
> --Paul Hoffman
>
> > URL:            https://www.ietf.org/internet-
> drafts/draft-hoffman-dns-over-http-00.txt
> _______________________________________________
> dnsoverhttp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsoverhttp
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Sep 2016 21:43:59 +0000

On Sep 20, 2016, at 1:40 PM, Ted Hardie <[email-masked]> wrote:
> Thanks for the draft.  Reading through it, it seems to posit a mechanism for providing a DNS API server that will serve the same function as a recursive resolver would now. 

We did not mean to limit it to recursive resolvers: it could be any DNS server. In Section 2.4, note the rd parameter can be set to 0. Maybe we should say this explicitly in the Introduction.

> Given that this is basically similar to a recursive resolver putting up a new API, I'm not sure why the complication of a non-standardized prefix is the right trade-off.  Why not standardize it?  If not standardized, why not use the well known URI mechanisms?

If folks prefer a standard prefix, we could certainly go that way. Having said that, if we started off with that instead, I strongly suspect that some would ask why we were forcing a particular URI on servers, and the modern IETF way is to give flexibility through discovery.

> I also note that this seems to be answering a different use case than Patrick and Martin were talking about in regards to server push.  With this, server push might be used for something like additional data, but you wouldn't see this in the same context as "normal" HTTPS connections, so server push from a content server wouldn't apply. Have I got that bit right?

Hopefully not. That is, we certainly want the server push model to work with our proposal.

--Paul Hoffman

---

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Sep 2016 15:01:56 -0700

On Tue, Sep 20, 2016 at 2:43 PM, Paul Hoffman <[email-masked]>
wrote:

> recursive resolver would now.
>
> We did not mean to limit it to recursive resolvers: it could be any DNS
> server. In Section 2.4, note the rd parameter can be set to 0. Maybe we
> should say this explicitly in the Introduction.
>
>
I guess the focus on discovery threw me there; clearly you wouldn't
provision authoritative servers with DHCP.

> > Given that this is basically similar to a recursive resolver putting up
> a new API, I'm not sure why the complication of a non-standardized prefix
> is the right trade-off.  Why not standardize it?  If not standardized, why
> not use the well known URI mechanisms?
>
> If folks prefer a standard prefix, we could certainly go that way. Having
> said that, if we started off with that instead, I strongly suspect that
> some would ask why we were forcing a particular URI on servers, and the
> modern IETF way is to give flexibility through discovery.
>
>
Well, ACME and others use well known URIs; that might be an approach to
consider (as the redirect gives you flexibility).

> So, if I am connected to https://blogplatform.example.com/, and it wants
me to know the dns info for securedimages.example.com, what does it do in
this mode?

Ted

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Sep 2016 22:37:43 +0000

On Sep 20, 2016, at 3:01 PM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Sep 20, 2016 at 2:43 PM, Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:

I guess the focus on discovery threw me there; clearly you wouldn't provision authoritative servers with DHCP.

Good point. We'll make that clearer in the -01.

Well, ACME and others use well known URIs; that might be an approach to consider (as the redirect gives you flexibility).

We should certainly consider it.

So, if I am connected to https://blogplatform.example.com/, and it wants me to know the dns info for securedimages.example.com<http://securedimages.example.com/>, what does it do in this mode?

We're quite open to suggestions here. I would hope that the pushing would be done in the same way that it is done for other resources in H2.

--Paul Hoffman

---

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Sep 2016 16:02:44 -0700

On Tue, Sep 20, 2016 at 3:37 PM, Paul Hoffman <[email-masked]>
wrote:

>
> https://blogplatform.example.com/, and it wants me to know the dns info
> for securedimages.example.com, what does it do in this mode?
>
>
> We're quite open to suggestions here. I would hope that the pushing would
> be done in the same way that it is done for other resources in H2.
>
>
>
In the server push case where the initial page is HTML containing
references to a bunch of resources, the server pushes the resources it
believes the client will need to render the HTML.  In your ID, you have a
different server provisioned by DHCP, RA, or config for resolving DNS
queries (the DNS API server is distinct from the content server, at least
as I read it now).  I'm not sure that use case and the server push use case
meld easily.

If you allow the content server to provision itself as a DNS API server,
then it could push resources, but you have a scoping problem, because it is
now a general-purpose recursive resolver.  That opens you up to some bad
attacks.  Imagine, for example,  that https://blogplatform.example.com/
references a resource at a quasi-competitor, https://likeengine.example/.
The first server can push a DNS answer that applies to all of
likeengine.example's resources.  The naive attack here blackholes
likeengine.example, but there are more subtle attacks, like giving you a
correct address for likeengine.example that happens to be pessimal (like
one at their datacenter on a different continent).  That can't be corrected
by DNSSEC, since it is correctly signed.

For the server push case, I pretty much assume that the only trusted DNS
resources from https://blogplatform.example.com/ will be those related to
example.com (hello, public suffix list and dbound!)  To fit that use case,
you'd need to have the DNS API server scoped in this case and unscoped in
other cases.

regards,

Ted

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Sep 2016 12:10:34 +1000

On 21 September 2016 at 09:02, Ted Hardie <[email-masked]> wrote:
> That can't be corrected by DNSSEC, since it is correctly signed.

It can be corrected by making another request.

I find the unstated point that you are pushing on quite interesting:
DNSSEC doesn't authenticate all the things that might be important in
the protocol.  Or maybe that there still remains some need for trust
in the protocol when it comes to recursive resolvers.

> example.com (hello, public suffix list and dbound!)

That would negate much of the value of having this sort of feature.  I
can see several ways around this.  The easiest being to scope the use
of the record until it can be independently verified.

The tracker can use alt-svc, or push its own records to update the
client's view and correct any infidelity.

If pushed record use is limited to the current site, then the tracker
might be affected, but that only negatively affects the perception of
the site that includes the tracker.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Sep 2016 12:21:35 +1000

Generally speaking, I like this.

1. caching is not discussed, seems like it might relate to TTL somehow
2. .invalid might be a poor choise:
https://tools.ietf.org/html/rfc6761#section-6.4
3. do we really need "id"?  adding extra correlators invites all sorts of crazy

The format is important: we should not just bungle a DNS message in a
response, for example, additionalRRs is an area that might be
addressed with server push.  The JSON format is somewhat in the right
direction, but it needs a lot of work (this is my go native comment,
consistent with your stated goal to be native).

---

From: Patrick McManus <[email-masked]>
Date: Wed, 21 Sep 2016 12:31:09 +0200

Paul - thanks for the draft! This is a good contribution - Some thoughts,
in no particular order:

* I don't have a strong opinion on whether or not the prefix can be
discoverable for some use cases, but it seems for h2 push it needs to be in
the .wk space in order to give the client enough context to recognize this
is dns data. given that, it might make sense to just use .wk everywhere
instead of making it discoverable.

* you have a todo on how trust works for prefixes based on IP instead of
name.. I think that's a little backwards - you want to think of a prefix
always using a name (for validation purposes) and in conjunction how to
bootstrap an address for it when necessary (i.e. allow optional stapling of
some sort)

* the discussion of content negotiation (aka Accept:) doesn't really add
anything to the existing http definition - i.e. using it might help you get
a content type you know how to decode. Perhaps having a MTI type (json?)
gives this more pertinence and helps deployability. Might as well get the
hard stuff on the table early :)

* the observation to set the cache age to the minimum of the included RR
TTL is good.. I wonder if you need to go farther in a couple of ways: a]
this impacts what you might want to bundle together as additional records
etc.. especially when pushing and those could be served as their own pushed
responses.. some advice on that would be useful b] I wonder (in the true
sense of I don't know) if there is difference in a recursive resolver in
just marking this as remaining max-age, or giving the max-age of the fresh
TTL and using Age headers to indicate how much of that has passed.. mnot
probably has keen insight into that - but it seems to me if the TTL is part
of the json or wire format response then this has implications for
revalidations and etags

* some advice on how to create etags might be helpful.. especially to the
extent that it is responding with tags that represent sets, traditional
version tracking might be really hard. hashes spring to mind as something
to consider - at the very least the issue should be discussed

* with respect to dnssec not authenticating everything we want I personally
have a bit of a shrug response.. because obviously adding trust to that
response just because of the ip address on the reply doesn't really add any
significant value either imo. Caching recursive resolvers tend to obscure
this stuff anyhow - especially big public ones. If we thought this was a
critical concern (I likely don't) then we could define some opt-in bit for
the zone owner to sign indicating they were ok with caches handing out
their data on their behalf. But I tend to agree with Martin that the http
client needs to be conservative about how far to propagate this information
- widening the circle as it gains confidence in it. That's what is
happening with other pushed data right now anyhow in practice (it gets
scoped to the resource that did the pushing, but after it is used
successfully it may end up in the general cache) - though feedback has been
that this is too conservative. its an interesting discussion.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Sep 2016 15:12:12 +0000

> 1. caching is not discussed, seems like it might relate to TTL somehow

We certainly meant to: it's an important part of HTTP. In the section on responses, we say:

In the HTTP responses, the HTTP cache headers are set to shortest DNS TTL in the response.
The HTTP responses SHOULD set the HTTP ETag headers as described in {{RFC7232}}.

Suggestions of what more we should say are greatly encouraged.

> https://tools.ietf.org/html/rfc6761#section-6.4

Very good point. If we keep with the "send this special name" scheme, we'll pick another.

> 3. do we really need "id"?  adding extra correlators invites all sorts of crazy

One of our stated goals was to allow any real DNS query. Although it would be bad practice, some servers might treat certain IDs as special.

> addressed with server push.  

Joe and I purposely kept this document agnostic to the response format. There will be different formats for different use cases, as Shane's draft shows.

> The JSON format is somewhat in the right

As a side note, I'm in an informal "last call" for draft-hoffman-dns-in-json with the intention of sending it to the ISE for Experimental status in a few weeks. There is some traffic about that on the DNSOP WG mailing list, and I'm happy to take offline comments as well. I'll be putting out a revised version in the next few days.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Sep 2016 15:24:25 +0000

On Sep 21, 2016, at 3:31 AM, Patrick McManus <[email-masked]> wrote:
> Paul - thanks for the draft! This is a good contribution - Some thoughts, in no particular order:
> 
> * I don't have a strong opinion on whether or not the prefix can be discoverable for some use cases, but it seems for h2 push it needs to be in the .wk space in order to give the client enough context to recognize this is dns data. given that, it might make sense to just use .wk everywhere instead of making it discoverable.

I'm maybe hearing a trend here. Does anyone have a strong argument for discoverability over .well_known?

> * you have a todo on how trust works for prefixes based on IP instead of name.. I think that's a little backwards - you want to think of a prefix always using a name (for validation purposes) and in conjunction how to bootstrap an address for it when necessary (i.e. allow optional stapling of some sort)

The TODO is more of a flag on "minefield of widely differing opinions". My current intention is to punt on the topic completely and point to an RFC or IESG statement.

> * the discussion of content negotiation (aka Accept:) doesn't really add anything to the existing http definition - i.e. using it might help you get a content type you know how to decode. Perhaps having a MTI type (json?)  gives this more pertinence and helps deployability. Might as well get the hard stuff on the table early :)

In the DNSOP WG, there isn't agreement that JSON should even be on standards track; the same is true for the wireformat draft. Personally, I don't see a strong reason for a mandatory-to-implement response format. For example, when the JSON format has settled, I intend to spin a really similar experimental document for CBOR in case the IoT folks want one.

> * the observation to set the cache age to the minimum of the included RR TTL is good.. I wonder if you need to go farther in a couple of ways: a] this impacts what you might want to bundle together as additional records etc.. especially when pushing and those could be served as their own pushed responses.. some advice on that would be useful b] I wonder (in the true sense of I don't know) if there is difference in a recursive resolver in just marking this as remaining max-age, or giving the max-age of the fresh TTL and using Age headers to indicate how much of that has passed.. mnot probably has keen insight into that - but it seems to me if the TTL is part of the json or wire format response then this has implications for revalidations and etags

Yeah, this is all good stuff that complicates DNS implementations too. We'll add a bit to the draft and then start a separate thread on it.

> * some advice on how to create etags might be helpful.. especially to the extent that it is responding with tags that represent sets, traditional version tracking might be really hard. hashes spring to mind as something to consider - at the very least the issue should be discussed

Sounds good.

> * with respect to dnssec not authenticating everything we want I personally have a bit of a shrug response.. because obviously adding trust to that response just because of the ip address on the reply doesn't really add any significant value either imo. Caching recursive resolvers tend to obscure this stuff anyhow - especially big public ones. If we thought this was a critical concern (I likely don't) then we could define some opt-in bit for the zone owner to sign indicating they were ok with caches handing out their data on their behalf. But I tend to agree with Martin that the http client needs to be conservative about how far to propagate this information - widening the circle as it gains confidence in it. That's what is happening with other pushed data right now anyhow in practice (it gets scoped to the resource that did the pushing, but after it is used successfully it may end up in the general cache) - though feedback has been that this is too conservative. its an interesting discussion.

...but one that I don't think belongs here. That is, the questions of "who do you trust for your answers, why do you trust them, should they let you trust them" come up occasionally in the DNS working groups as well. If we get an answer to those from the DNS world, that answer needs to be reflected in this protocol, but I don't think the fact that the queries are going over HTTP over TLS makes these queries special.

--Paul Hoffman

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Sep 2016 10:21:08 -0700

> It can be corrected by making another request.
You'll get a different answer if you make another request using a different
method or DNS API server.

> of the record until it can be independently verified.
Using a browser as an example, if you scope this such that server pushed
DNS records are only used in the same tab/browser context, then I agree
with you; the threat model I am concerned about is one where it gets
blended into the general name resolution pool.  That means the usual TTL
model of the DNS is not quite the same if you getting the records from this
method, and I think that has to be called out.

> the site that includes the tracker.

I tam note sure "site" is quite right here, but I agree with the
sentiment--if you push bad records, they should affect only the perception
of the site that pushed them.

Ted

---

From: Patrick McManus <[email-masked]>
Date: Wed, 21 Sep 2016 20:41:43 +0200

On Wed, Sep 21, 2016 at 5:24 PM, Paul Hoffman <[email-masked]>
wrote:

> In the DNSOP WG, there isn't agreement that JSON should even be on
> standards track; the same is true for the wireformat draft. Personally, I
> don't see a strong reason for a mandatory-to-implement response format. For
> example, when the JSON format has settled, I intend to spin a really
> similar experimental document for CBOR in case the IoT folks want one.
>
>
imo its important to remember that http content negotiation is only
advisory.. if you send Accept: foo it certainly increases your chances of
receiving foo in the response but it doesn't obligate the response to be in
foo format.. an http dns client could find the whole thing much more useful
to implement if it had knew there was a mti lcd available it could rely on
if foo wasn't available - which still means the specification can be
neutral about allowing any number of formats in addition to the mti one.
I've heard json tossed around, but I didn't mean to limit discussion to it
- I just think having an mti format is really really helpful for interop.

but maybe others don't. just thought it was worth a second try :)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Sep 2016 11:16:21 +1000

> Joe and I purposely kept this document agnostic to the response format. There will be different formats for different use cases, as Shane's draft shows.

I think that would be a mistake.  Pick one and polish it.

> As a side note, I'm in an informal "last call" for draft-hoffman-dns-in-json with the intention of sending it to the ISE for Experimental status in a few weeks. There is some traffic about that on…

Why do I hear so much about the ISE with these things?  This seems
like work that a working group should take on.  I'll be that we could
have a working group pretty quickly if it came to that.

Frankly, I don't think that the JSON spec is anywhere near as ready as
your proposed protocol spec, so I'm surprised to hear you want to push
it out with an RFC number on it.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Sep 2016 11:19:15 +1000

> I'm maybe hearing a trend here. Does anyone have a strong argument for discoverability over .well_known?

Yes, I think that papers over the real problem.

The problem that I think Patrick is worried about is one where
arbitrary content can make claims about DNS answers.  The problem Ted
referenced is that arbitrary servers can make the same sorts of
claims.  We need a threat model and some systemic way of thinking
about the problem before we leap to conclusions.

.well-known only narrows the problem, it doesn't solve it.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Sep 2016 11:20:16 +1000

On 22 September 2016 at 04:41, Patrick McManus <[email-masked]> wrote:
> I just think having an mti format is really really helpful for interop.

Yes, I would go beyond that and say that it's necessary.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Sep 2016 11:24:22 +1000

> method or DNS API server.

Well, you might assume that the last response is the best, otherwise
we're into the whole "man with two clocks" paradigm of protocol
engineering.  The point I was trying to make being that if you don't
trust a particular server to provide you an answer that is generally
usable, then ask a server you do trust to that end.

Sure, the answers might be different, but the worst outcome I can
currently imagine is bad routing.  That is, assuming the next thing
you do is authenticate as all good boys and girls have been taught to
do.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Sep 2016 01:32:38 +0000

> I think that would be a mistake.  Pick one and polish it.

Sorry, this just feels wrong. For example, why should a DNS application have to add a JSON processor that it will never use if it wants to get responses in DNS wire format?

> Why do I hear so much about the ISE with these things?

Because it's an experimental document and no obvious WG to discuss it in.

>  This seems

If you want to find an AD who wants to sponsor this, great. At that point, it could go on standards track. To me, this is asking the IESG to do much more work than it needs to for a fairly small document.

> it out with an RFC number on it.

As I keep saying, I'm quite open to comments on it. I've gotten plenty from the DNS community over the past few years, but we could have missed stuff you're seeing.

--Paul Hoffman

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Sep 2016 15:52:37 +1000

> Sorry, this just feels wrong. For example, why should a DNS application have to add a JSON processor that it will never use if it wants to get responses in DNS wire format?

That's where I think we have a disconnect on use cases.  I want to
make DNS more accessible to application developers.  I think that some
others want to take advantage of the fact that no middlebox dares to
break HTTP.  The wire format in antithetical to my goal.  My thesis is
that if we have the wire format, there's no incentive to do the other
thing.

> Because it's an experimental document and no obvious WG to discuss it in.

The activity on this list leads me to conclude that this is a
temporary situation.  And "experimental" is not doing this justice; if
someone wants to deploy this for realsies - and that seems like it has
some decent chance of happening - then it's worth doing the protocol
for realsies too.

> If you want to find an AD who wants to sponsor this, great. At that point, it could go on standards track. To me, this is asking the IESG to do much more work than it needs to for a fairly small do…

I have to disagree about this being small.  Done right, this could be
a big deal.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Sep 2016 14:43:18 +0000

> that if we have the wire format, there's no incentive to do the other

We'll disagree on two axes there.

- You should not be able to prevent a community from using the format they want as long as they use HTTP properly, and "properly" is the goal of this document. Some DNS communities need extremely fast processing of the data and no problems with escaping, so JSON will not serve them well.

- You haven't been following the discussions over the years on DNSEXT and DNSOP. The wire format is actually less popular than JSON. If you somehow managed to make dns-over-http be a single output format (which I hope you don't), I believe that the DNS community would prefer JSON.

> some decent chance of happening - then it's worth doing the protocol

If you believe that there will be actual deployment of the JSON format in the next year, I'm happy to keep cycling the draft in a WG or as AD-sponsored standards track. To date, I think I'm the only user (and barely that: I rolled my own more kludgy format a few years ago and still mostly use that).

> I have to disagree about this being small.  Done right, this could be

Sounds good to me (or at least to my ego).

--Paul Hoffman

---

From: Patrick McManus <[email-masked]>
Date: Thu, 22 Sep 2016 18:24:45 +0200

On Thu, Sep 22, 2016 at 7:52 AM, Martin Thomson <[email-masked]>
wrote:

> I'm going to diverge a bit from both you and Paul on this point. I'm fine
with having multiple representations - I think that's a very HTTPish thing
to do and Paul makes a case for different environments reasonably wanting
different things. However, you don't really need a DNS-over-HTTP effort to
accomplish that.. the binding has the chance to further constrain the
question in order to reduce some of the ambiguity of basic HTTP and make it
more useful. If you implement a generic HTTP client there is no particular
reason to think that you would semantically be able to understand DNS data
coming from a server even if you interoperate on a HTTP level.. but if you
implement a DNS-over-HTTP client I would like to think that you would be
confident of being able to exchange DNS info with any server that pledged
fidelity to the same specification - thus MTI as a baseline but go ahead
and use content negotiation to have other representations if you like.

> I have to disagree about this being small.  Done right, this could be

+1

---

From: Patrick McManus <[email-masked]>
Date: Thu, 22 Sep 2016 18:29:01 +0200

On Thu, Sep 22, 2016 at 3:19 AM, Martin Thomson <[email-masked]>
wrote:

> arbitrary content can make claims about DNS answers.
>

That's one small bit, but my focus is actually more prosaic.

unless you are pushing into a .wk that carries a semantic meaning, the
client really doesn't know what to do with this application/json-dns data.
Sure its DNS data but should it be used for resolutions? Maybe its part of
a file system backup, or the archive of a dataset from some uni project, or
whatever.. I think we need more info than "thiis is DNS info" to use it for
a resolution - and a path seems like the way to express that to me.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 22 Sep 2016 09:36:28 -0700

On Wed, Sep 21, 2016 at 6:24 PM, Martin Thomson <[email-masked]>
wrote:

> engineering.

Sorry, I apparently wasn't clear.  The point I was making was in response
to your statement in this part of the thread:

Ted: That can't be corrected by DNSSEC, since it is correctly signed.
>
> Martin: It can be corrected by making another request.
>
> I was trying to point that in order to test this using your method you
have to have access to a different DNS API server or a different protocol
with the same security properties (e.g. DNS over TLS or DNS over DTLS).

Using either of those test methods is also going to be bad for latency, so
it is not going to happen in the common case, unless we explicitly scope
things so that it does.  You could imagine, for example, a server marking
an answer as reusable and the client testing those before moving them from
a context-specific cache to a general cache.

I think the safest thing to do is to treat all of these answers as
explicitly scoped to the context in which they were received, but that's
actually a big change to the consistency model.  It's also not really
fixable with the usual DNS TTL tricks, because the action required is "ask
a different server" not "ask again".  Re-asking the same server at TTL
expiration doesn't improve the security properties at all.

Hope that is clearer,

Ted

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Sep 2016 15:13:56 +1000

On 23 September 2016 at 02:24, Patrick McManus <[email-masked]> wrote:
> MTI as a baseline but go ahead and use content negotiation to have other
> representations if you like.

That's where I'm headed.  I don't like interop failure, and not having
an MTI is a stop down that road.