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

[Tony Finch]

Warren Kumari  wrote:
>
> 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.

:-D

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

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

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

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

[Robert Edmonds]

IETF Secretariat wrote:
> 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/

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:

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

   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

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

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

[Warren Kumari]

On Mon, Jul 11, 2016 at 3:33 PM, Tony Finch  wrote:
>
> Warren Kumari  wrote:
>>
>> 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.
>
> 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.

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

>> 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).
>
> That seems like a useful refinement :-)
>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
>
>



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

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

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

[Tony Finch]

 
Warren Kumari  wrote:
>
> 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.
 
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...
 
> 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).
 
That seems like a useful refinement :-)
 
Tony.
--
f.anthony.n.finch    http://dotat.at/  -  I xn--
  zr8h punycode
 
 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Thu, Jul 7, 2016 at 5:32 AM, Tony Finch  wrote:
> 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   typename.
>
> 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





>
> Tony.
> --
> f.anthony.n.finch    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.



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

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

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

[fujiwara]

> From: "Jiankang Yao" 
>>* My idea
> 
>>  I prefer multiple query sections (with some restrictions)
>>  and merged answers.
> 
>>  multiple query examples may be
>>NAME A + NAME  + MX
>>NAME A + NAME  + _443._tcp.NAME TLSA
>>NAME A + NAME  + _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

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.

--
Kazunori Fujiwara, JPRS 

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

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

[Tony Finch]

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

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

Tony.
-- 
f.anthony.n.finch    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.

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

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

[Jiankang Yao]

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"



>* My idea

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

>  multiple query examples may be
>NAME A + NAME  + MX
>NAME A + NAME  + _443._tcp.NAME TLSA
>NAME A + NAME  + _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___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

In message 
, Warren Kumari writes:
> On Wed, Jul 6, 2016 at 6:35 PM, John Heidemann  wrote:
> > On Wed, 06 Jul 2016 12:21:58 -0700, Wes Hardaker wrote:
> >>Warren Kumari  writes:
> >>
> >>> The multiple query example, and multiple TYPEs are interesting, but
> >>> 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.
> >
> > 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 +  + 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.)
> 
> Yup, kinda - except that (currently) recursives appear to ignore
> "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.

> 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...
> 
> 
> >
> >-John Heidemann
> >
> 
> 
> 
> -- 
> 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
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

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

[Warren Kumari]

On Wed, Jul 6, 2016 at 6:35 PM, John Heidemann  wrote:
> On Wed, 06 Jul 2016 12:21:58 -0700, Wes Hardaker wrote:
>>Warren Kumari  writes:
>>
>>> The multiple query example, and multiple TYPEs are interesting, but
>>> 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.
>
> 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 +  + 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.)

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


>
>-John Heidemann
>



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

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

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

[John Heidemann]

On Wed, 06 Jul 2016 12:21:58 -0700, Wes Hardaker wrote: 
>Warren Kumari  writes:
>
>> The multiple query example, and multiple TYPEs are interesting, but
>> 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.

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

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

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

[Wes Hardaker]

fujiw...@jprs.co.jp writes:

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

>   I think the multiple queries in one request is not related to DNSSEC
>   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

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

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

[Wes Hardaker]

Warren Kumari  writes:

> The multiple query example, and multiple TYPEs are interesting, but
> 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

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

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

[Paul Hoffman]

On 6 Jul 2016, at 3:54, Ray Bellis wrote:


On 06/07/2016 10:09, fujiw...@jprs.co.jp wrote:

* My idea

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

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


  Many people may dislike QDCOUNT != 1.
  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.


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

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

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

[Ray Bellis]

On 06/07/2016 10:09, fujiw...@jprs.co.jp wrote:

> 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  + MX
> NAME A + NAME  + _443._tcp.NAME TLSA
> NAME A + NAME  + _sip._udp.NAME SRV + _sips._tcp.NAME SRV + ...
> 
>   Many people may dislike QDCOUNT != 1.
>   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

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

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

[fujiwara]

> From: IETF Secretariat 
> 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/

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  + MX
NAME A + NAME  + _443._tcp.NAME TLSA
NAME A + NAME  + _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 

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

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

[Bob Harold]

On Fri, Jul 1, 2016 at 3:51 AM, IETF Secretariat <
ietf-secretariat-re...@ietf.org> wrote:

>
> 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/
>
>
>
I support and will review.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop