Subject: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"

From: IETF Secretariat <[email-masked]>
Date: Fri, 01 Jul 2016 00:51:16 -0700

The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state 
Candidate for WG Adoption (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/

---

From: Bob Harold <[email-masked]>
Date: Tue, 5 Jul 2016 13:26:01 -0400

> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
I support and will review.

---

From: [email-masked]
Date: Wed, 06 Jul 2016 18:09:40 +0900 (JST)

> From: IETF Secretariat <[email-masked]>

I missed previous discussions (at dnsext).
However, there were many discussions about multiple queries in one request.

We need summaries of previous discussions,
and need to consider why many idea stopped.

* For the draft,

  Using unstructured data (TXT format) is not good.

  I agree query name restriction (Additional records MUST be leaf
  records at the same node in the DNS tree).

  I think the multiple queries in one request is not related to DNSSEC
  and TCP connection. They are separated elements.

* My idea

  I prefer multiple query sections (with some restrictions)
  and merged answers.

  multiple query examples may be
    NAME A + NAME AAAA + MX
    NAME A + NAME AAAA + _443._tcp.NAME TLSA
    NAME A + NAME AAAA + _sip._udp.NAME SRV + _sips._tcp.NAME SRV + ...

  Many people may dislike QDCOUNT != 1.
  EDNS0 option which contain additional query section may be possible.

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: Ray Bellis <[email-masked]>
Date: Wed, 6 Jul 2016 11:54:15 +0100

>   EDNS0 option which contain additional query section may be possible.

and there's my idea (draft-bellis-dnsext-multi-qtypes-02) which only
permits a single QNAME, but supports additional QTYPEs via an EDNS0 option.

Ray

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 06 Jul 2016 07:34:03 -0700

> permits a single QNAME, but supports additional QTYPEs via an EDNS0 

Of these three solutions to the same problem, I prefer Ray's. It seems 
less work to implement and less likely to trip up naively-implemented 
DNS stacks.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Wed, 6 Jul 2016 14:12:34 -0400

On Wed, Jul 6, 2016 at 10:34 AM, Paul Hoffman <[email-masked]> wrote:
> Of these three solutions to the same problem, I prefer Ray's. It seems less
> work to implement and less likely to trip up naively-implemented DNS stacks.

These solve different use cases.

The multiple query example, and multiple TYPEs are interesting, but
solves a different problem -- for multiple queries/ TYPEs  the
requestor needs to already know *what* other questions it needs to
ask;  in many cases (for example, loading resources on a web page,
resolving SRV targets, etc) the requestor doesn't know this until it
has started doing work, and only then can it discover what else it
needs.

For example, when I load https://www.paypal.com the page will cause me
to load resources from t.paypal.com, b.stats.paypal.com, c.paypal.com
and slc.stats.paypal.com.

www.yahoo.com needs resources from geo.yahoo.com, comet.yahoo.com and
beap-bc.yahoo.com.
Without resolving www.yahoo.com and fetching / parsing the HTML I have
no way of knowing what other names I'll need.

Resolving  _xmpp-client._tcp.jabber.org gives me back:
_xmpp-client._tcp.jabber.org. 899 IN SRV 30 30 5222 hermes2.jabber.org.

I now need to make a separate query for hermes2.jabber.org -- I
wouldn't know that until the first query completes.

W

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

-- 
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

---

From: Ray Bellis <[email-masked]>
Date: Wed, 6 Jul 2016 19:30:40 +0100

> wouldn't know that until the first query completes.

I see those as two _very_ different use cases.

The Paypal and Yahoo examples are (IMHO) a seriously bad layer violation
- it's putting webpage-specific intelligence into the DNS layer.

Ray

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 06 Jul 2016 12:21:58 -0700

Warren Kumari <[email-masked]> writes:

> solves a different problem

Exactly.  IMHO, we really need both solutions:

1) the ability to ask multiple questions
2) the ability for a server to respond with authoritative answers a user
   will likely ask for next, before it knows what to ask.
-- 
Wes Hardaker
Parsons

---

From: Shane Kerr <[email-masked]>
Date: Wed, 6 Jul 2016 21:25:56 +0200

Paul,

At 2016-07-06 07:34:03 -0700

> less work to implement and less likely to trip up naively-implemented 

I think that I agree.

In either the case of that or Warren's draft, I reiterate that I think
that the biggest win is from the stub to resolver state, where we can
in principle save almost 50% of the queries that the resolver answers.

I think advice to stubs (and possibly resolvers) would help make Ray's
draft more useful.

For stubs the recommendation could be as simple as:

1. When starting, send a query for ID.SERVER or the like with the multi
   QTYPE option (QTCOUNT=0), and look for the QTD bit in the reply.

2. If this works, future queries to the local resolver can use multi
   QTYPES. Should a answer come back without the QTD bit, then the stub
   should immediately stop using multi QTYPES.

For resolvers, the advice probably should be expanded. My thinking is
that a resolver who wants to try this should include the multi QTYPE
option with the first query to an authority server for probing. If a
resolver doesn't know whether a server supports multi QTYPE then it can
go ahead and do queries in parallel the old fashioned way - while
probing. :) (Surely any production server will have to do back-off in
the same way that they do EDNS0 back-off - it seems like this would be
helpful to note in a document, but maybe that is over-specification.)

Cheers,

--
Shane

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 06 Jul 2016 12:35:19 -0700

>   Using unstructured data (TXT format) is not good.

Thanks for the feedback on that.  I have wondered heavily on that
topic.  It was originally written as a text format, and we have a lot of
other cases where such text parsing exists (SPF being an example).  As
the world moves more and more to text based parsing for everything,
which I hardly say is a good thing, I wonder what the right format of
future DNS records should be.  It sounds like a good worthwhile
discussion in its own right.

In the mean time, a binary format for the record would be just fine in
my view and the record already lends itself to such a format since it's
very structured data.  It would be worth discussing once the concept in
the draft gets accepted for work by the WG.  I'm (personally) certainly
not opposed to a binary on-the-wire record format.

>   and TCP connection. They are separated elements.

We dropped the requirement for TCP in the latest version already (-03).

DNSSEC is necessary to avoid cache poisoning of illegal data (IE, to
prove you're the parent of the data as opposed to a grand parent).
-- 
Wes Hardaker
Parsons

---

From: Warren Kumari <[email-masked]>
Date: Wed, 6 Jul 2016 16:06:48 -0400

> - it's putting webpage-specific intelligence into the DNS layer.

It's not really "putting webpage-specific intelligence into the DNS
layer", rather it is including related DNS records -- I used the
(admittedly poor) examples of Paypal / Yahoo simply because they were
easily understood cases where the recursive wouldn't know what else it
needs to ask.

I'd think that one deployment scenario would be that authoritative
server operators run a script against their query logs - this script
would look for cases where recursive ask for X, and then always come
back within <timeframe> and ask for Y, with probability >=Z.

W

---

From: John Heidemann <[email-masked]>
Date: Wed, 06 Jul 2016 15:35:04 -0700

>   will likely ask for next, before it knows what to ask.

Just an observation:

you can do (1) ask multiple questions today with separate queries over
one TCP connection.  Pipeline them and they may even pack down to one
packet (after connection setup).  TCP handles all the edge conditions
about packet size.  (There is some "overhead" in that you get muliple
DNS headers, but mutliple headers also mean you there is no ambiguity
about which query the response code applies to.)

Using pipelined TCP does not require protocol changes, but it may
require implementation changes.  (As per RFC-7766.)

TCP perhaps solves the "give me A + AAAA + MX" case.

Case (2) is the ability to have a server give back the answers to
questions you did not yet ask.  Isn't that what the "additional" section
is for?   (With or without TCP.)

   -John Heidemann

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Jul 2016 08:59:24 +1000

In message <[email-masked]>
> wouldn't know that until the first query completes.

But the nameserver knows and already does add hermes2.jabber.org
to the answer if it has it in cache.  There is nothing preventing
existing recursive servers recursing for hermes2.jabber.org if there
is a cache miss and only returning a answer to _xmpp-client._tcp.jabber.org
once hermes2.jabber.org A and AAAA have resolved.  Its just a matter
of coding.

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 6 Jul 2016 19:20:52 -0400

> is for?   (With or without TCP.)

Yup, kinda - except that (currently) recursives appear to ignore
"gratuitous" additional records

AFAICT[0], currently recursive servers will not trust answers to
questions which have not been asked (and are not required supporting
information (like glue))  -- this was, AFAIK, originally to avoid
things like https://www.cs.columbia.edu/~smb/papers/dnshack.pdf

Now, with DNSSEC recursive servers have a reason to be able to trust
this data, and so the additional section can be used again for, um,
additional information[1].

W
[0]: Of course, it is entirely possible I'm wrong. I tested this with
some crafted responses (with scapy), but I could have messed up the
testing.

[1]: Earlier versions of this document called these "ADDitional"
records, but that got too confusing...

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Jul 2016 09:28:24 +1000

In message <CAHw9_i+VgYXvQqMgegQRBLgobZ+=[email-masked]>
> "gratuitous" additional records

They also ignore CNAME targets but that doesn't stop people wanting
CNAME over SRV.  The critical thing is does the recursive server
add the additional records or not.  The application can then decide
whether to use the records or not.

A recursive server can also prefetch SRV targets if it has a cache
miss if it just doesn't stall the SRV query.

---

From: "Jiankang Yao" <[email-masked]>
Date: Thu, 7 Jul 2016 09:33:27 +0800

From: fujiwara
Date: 2016-07-06 17:09
To: dnsop
Subject: Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"

>    NAME A + NAME AAAA + _sip._udp.NAME SRV + _sips._tcp.NAME SRV + ...

Dear Fujiwara-san,

Your points/scenarios  fall in the Draft
 https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-00.txt

pls help to take a look.

thanks.

Jiankang Yao

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Jul 2016 10:32:42 +0100

Regarding the format of EXTRA RRs, it's better to use a list of RRs rather
than a list embedded in one RR. And a single label isn't enough, e.g.
TLSA.

So I suggest the presentation format should be like

	EXTRA	type	name.

and the wire format should be a 16 bit type followed by an uncompressed name.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire: Variable 3 or 4, becoming southwesterly 4 or 5. Slight or
moderate. Rain at first. Good, occasionally moderate at first.

---

From: [email-masked]
Date: Thu, 07 Jul 2016 20:05:10 +0900 (JST)

> From: "Jiankang Yao" <[email-masked]>
>>* My idea
> 

Thanks.

I read the draft. It has similar point and different point.

I cannot understand the UAQ bit necessity.
When a client sends a query with AQ EDNS0 option,
if the server knows the AQ EDNS0 option, the server can answer AQ response
because the client knows the AQ extension.
If the server does not know the AQ EDNS0 option, the server drops the unknown option.

Another comment: the response format is very complicated.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 11 Jul 2016 15:23:02 -0400

> and the wire format should be a 16 bit type followed by an uncompressed name.

Hmmm... I think that this sounds reasonable, possibly with a minor tweak.
Initially the EXTRA RR was never intended to be something that could
be queried - the EXTRA (nee ADDitional) record only existed to allow
copying from the master to the slave (they were instructions to the
nameservers, not actual RR). Now that we allow querying directly, the
RR type needs more discussion.

Wes and I will chat more in Berlin, but I'd like to be able to have a
way to insert a preference into the RR as well (if there are N extra
records, but only space for M, I'd like to be able to indicate which
are the M to include).
How would:
EXTRA pref type name
work for you? (pref would likely be an octet).

W

---

From: Tony Finch <[email-masked]>
Date: Mon, 11 Jul 2016 20:33:54 +0100

> RR type needs more discussion.
 
One thing I vaguely wondered about is how this interacts with RFC 2181
trustworthiness ranking.
 
If you have a validating resolver then it can accept the additional
records OK. That isn't safe if you aren't validating or if the zone
is unsigned.
 
But maybe the contents of the EXTRA RRset are safe? The resolver can go
and get the real answers asynchronously. (Probably needs a quota to
avoid amplification.) However I don't know how an authority would decide
whether to fill in the additional data or the EXTRA RRs...
 
> work for you? (pref would likely be an octet).
 
That seems like a useful refinement :-)
 
Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--
  zr8h punycode

---

From: Warren Kumari <[email-masked]>
Date: Mon, 11 Jul 2016 16:10:21 -0400

On Mon, Jul 11, 2016 at 3:33 PM, Tony Finch <[email-masked]> wrote:
> If you have a validating resolver then it can accept the additional records
> OK. That isn't safe if you aren't validating or if the zone is unsigned.

Yup -- the document says that you may only do this if you DNSSEC validate.

"4.  Returning multiple answers

 [snip ]

   In order to include additional records in a response, these
   conditions need to be met:

   1.  Additional records MUST only be included when the Name Server is
       authoritative for the zone, and the records to be returned are
       DNSSEC signed.
..."

and

"8.  Use of Additional information

   When receiving additional records in the additional section, a
   resolver follows certain rules:

   1.  Additional records MUST be validated before being used."

>
> But maybe the contents of the EXTRA RRset are safe? The resolver can go and
> get the real answers asynchronously. (Probably needs a quota to avoid
> amplification.)

Yup - it could be used to instruct a (non-validating) resolver to
please go off and start fetching this list of other records... but,
seeing as everyone already validates (right?!) we don't suggest this.

> However I don't know how an authority would decide whether
> to fill in the additional data or the EXTRA RRs...
>

Hmm. It seems that we have done a poor job of wording this bit. We
meant to say that this information is always placed in the additional
section (assuming that support is signalled). The only exception to
this is if someone queries for the EXTRA record explicitly.

But, Wes, Yan and I (and anyone else interested. Tony?) will discuss
the best way to encode this in the zone file in Berlin, and also
better explain the "always stuff this in additional (because, well, it
is additional), but people can ask if they really want to..." bit
W

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 11 Jul 2016 21:10:26 -0400

> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/

Hi,

I've read the -03 version of this draft and previous mailing list
discussion about prior versions of the draft and I don't support its
adoption. There doesn't seem to be a strong (preferably data-driven)
reasoning to justify the mechanism described in the draft, and in
previous discussion [0] it's described as being, essentially, just an
interesting optimization.

[0] https://mailarchive.ietf.org/arch/msg/dnsop/NruMO-whi7UW7gzXF-gu9OrYTMg

For keeping popular records in cache, pre-fetching (e.g.
draft-wkumari-dnsop-hammer) would seem like a less disruptive technique
since it can be implemented entirely by the recursive name server, and
it can also be applied to unsigned records, of which there are still
quite a few. Pre-fetching probably doesn't help unpopular records as
much (if at all), but unpopular records (by definition) don't have as
many users as popular records.

About the draft itself:

I wondered why signalling is necessary.

• RFC 1034 §4.3.2 “Algorithm”, step 6:

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.

This would seem to let an authoritative nameserver add any records
deemed “useful” to the additional section of a response. (The RFC says
“query” instead of “response” here, but that is almost certainly an
erratum.)

• RFC 2181 §5.4.1 “Ranking data”:

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

   When DNS security [RFC2065] is in use, and an authenticated reply has
   been received and verified, the data thus authenticated shall be
   considered more trustworthy than unauthenticated data of the same
   type. […]

This is the prohibition on promoting additional section RRs to answer
section RRs in the responses returned to clients. But the prohibition
only applies to unauthenticated RRs. It actually sub-divides the
“Additional information from an authoritative answer” rank into two
sub-ranks based on DNSSEC status.

Is there anywhere else in the DNS/DNSSEC specs that would prohibit that
promotion, where the additional record is DNSSEC secure? Otherwise I
would think that nameservers could populate the additional section with
whatever they want, and security-aware recursive name servers could pick
up secure RRs from the additional section, and cache them such that they
would be returned in the answer section to clients, all without any
signalling. So the EXTRA bit could be eliminated?

• Section 8 “Use of Additional information” from the draft:

   1.  Additional records MUST be validated before being used.

   2.  Additional records SHOULD be annotated in the cache as having
       been received as Additional records.

   3.  Additional records SHOULD have lower priority in the cache than
       answers received because they were requested.  This is to help
       evict Additional records from the cache first (to help prevent
       cache filling attacks).

   4.  Recursive resolvers MAY choose to ignore Additional records for
       any reason, including CPU or cache space concerns, phase of the
       moon, etc.  It may choose to accept all, some or none of the
       Additional records.

is very confusing to me. I think it doesn't apply to additional records
that are the normal result of additional section processing? I think it
is actually talking about “extra” records that are undergoing an
upgrade.

Basically, this whole idea seems to me like something that can already
be implemented today, without any specification work other than the
format of the EXTRA RR. But the EXTRA RR is just configuration
information and you don't strictly need it until you want to distribute
it interoperably.

-- 
Robert Edmonds

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Jul 2016 12:00:51 +0100

> seeing as everyone already validates (right?!) we don't suggest this.

:-D

> is additional), but people can ask if they really want to..." bit

Sorry, I was being too terse. I was thinking that in some cases (lack of
DNSSEC) the resolver might want to receive the EXTRA RRset itself rather
than the other records that it lists, so the resolver can go and fetch the
other records. But on second thoughts this is silly, because the resolver
can use the other records as a fetch hint just as well as it could use an
EXTRA RRset as a fetch hint.

(I'm afraid I won't be in Berlin.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fair Isle: Northwest 5 or 6, decreasing 4 at times. Moderate. Rain or showers,
fog patches in north. Moderate or good, occasionally very poor in north.