Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

2016-07-11 Thread Marek Vavruša
On Mon, Jul 11, 2016 at 10:39 PM, John R Levine  wrote:
>> for a web to DNS proxy to decide to send a reply back, it would need to
>> consider it complete?
>>
>> Or are you proposing that the http server would start streaming back the
>> payload as it received the (possibly out of order) replies?
>
>
> I was thinking that the proxy would get all the queries from the DNS
> request, deal with them however it wants, maybe stuff them to a nearby DNS
> cache with TCP if it pipelines properly, or split them up into separate
> requests if it doesn't, then collect the responses and send them back when
> it has them, which I guess would constitute streaming.  RFC 7766 says that
> out-of-order is fine.

Without HTTP/2 each request, clients would need to start a separate
connection to get parallel processing, which means TCP handshake and
potentially a TLS and more bookkeeping code. So client makes requests
to proxy over HTTP/2 to mitigate the costs (here 7766 doesn't apply).
Then proxy translates incoming HTTP/2 multiplexed requests into either
DNS/TCP queries to origins (here 7766 helps)  or plain old DNS
(additional costs and bookkeeping). Server sends back DNS responses to
proxy, which in turn translates them to DNS/HTTP answers. So both
DNS/TCP out-of-order processing and DNS/HTTP out-of-order processing
is desirable here.

> I suppose with http/2 we get two-way streaming more or less for free.
>
> R's,
> John

Yep, the proxy can also push DNS answers to client ahead of time,
which is interesting and something DNS servers can't do right now. On
another note - this proposal kind of competes with DNS over HTTP
encoded in JSON. While that one doesn't transport exact byte-by-byte
DNS messages, it's much more consumer-friendly and elegant than
piggybacking binary data. I wonder why that one is not getting more
attention.

Marek

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

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


Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

2016-07-11 Thread Marek Vavruša
RFC 7766 is about DNS/TCP not about DNS/HTTP, the order of processing
has to be determined by the wrapping protocol. You would get it for
free if this draft was about TCP over HTTP or HTTP over DNS/TCP, but
it's not.

Marek


On Mon, Jul 11, 2016 at 10:32 PM, John R Levine  wrote:
>>> Don't you get this automatically if it's treated as a TCP DNS
>>> connection?  You stuff a bunch of requests down the pipe, and you get
>>> back a bunch of responses.
>>> See RFC 7766.
>
>
>> You get queueing for free, but not pipelining and out-of-order
>> responses, that has to be defined.
>
>
> RFC 7766 says you should get pipelining and out-of-order responses on TCP
> DNS.  Take a look.
>
> Even if the underlying DNS server that the proxy is using can't do it, any
> newly written proxy should provide TCP DNS the way 7766 says it should.
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.

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


Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

2016-07-11 Thread John R Levine
for a web to DNS proxy to decide to send a reply back, it would need to 
consider it complete?


Or are you proposing that the http server would start streaming back the 
payload as it received the (possibly out of order) replies?


I was thinking that the proxy would get all the queries from the DNS 
request, deal with them however it wants, maybe stuff them to a nearby DNS 
cache with TCP if it pipelines properly, or split them up into separate 
requests if it doesn't, then collect the responses and send them back when 
it has them, which I guess would constitute streaming.  RFC 7766 says that 
out-of-order is fine.


I suppose with http/2 we get two-way streaming more or less for free.

R's,
John

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


Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

2016-07-11 Thread Adrien de Croy


for a web to DNS proxy to decide to send a reply back, it would need to 
consider it complete?


Or are you proposing that the http server would start streaming back the 
payload as it received the (possibly out of order) replies?


Maybe instead should use WebSockets


-- Original Message --
From: "John R Levine" 
To: "Marek Vavruša" 
Cc: "dnsop" 
Sent: 12/07/2016 3:32:51 p.m.
Subject: Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http


Don't you get this automatically if it's treated as a TCP DNS
connection?  You stuff a bunch of requests down the pipe, and you get
back a bunch of responses.
See RFC 7766.



You get queueing for free, but not pipelining and out-of-order
responses, that has to be defined.


RFC 7766 says you should get pipelining and out-of-order responses on 
TCP DNS.  Take a look.


Even if the underlying DNS server that the proxy is using can't do it, 
any newly written proxy should provide TCP DNS the way 7766 says it 
should.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

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


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


Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

2016-07-11 Thread John R Levine
I guess presuming that the back end will use TCP for DNS you could do this, 
but I would imagine that's not always the case?


If it doesn't, there's a lot of queries that will fail, particularly with 
DNSSEC included.  See RFC 7766.


R's,
John

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


Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

2016-07-11 Thread John R Levine

Don't you get this automatically if it's treated as a TCP DNS
connection?  You stuff a bunch of requests down the pipe, and you get
back a bunch of responses.
See RFC 7766.



You get queueing for free, but not pipelining and out-of-order
responses, that has to be defined.


RFC 7766 says you should get pipelining and out-of-order responses on TCP 
DNS.  Take a look.


Even if the underlying DNS server that the proxy is using can't do it, any 
newly written proxy should provide TCP DNS the way 7766 says it should.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

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


Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

2016-07-11 Thread Marek Vavruša
On Mon, Jul 11, 2016 at 10:06 PM, John Levine  wrote:
>>So I suggest some thought should be given to reducing round-trips by
>>allowing for multiple DNS request payloads in a single HTTP request
>>message, and multiple DNS response payloads in an HTTP response message.
>
> Don't you get this automatically if it's treated as a TCP DNS
> connection?  You stuff a bunch of requests down the pipe, and you get
> back a bunch of responses.
>
> See RFC 7766.
>
> R's
> John

You get queueing for free, but not pipelining and out-of-order
responses, that has to be defined.
The draft mentions this, but I think at this point it should just
depend on HTTP/2,
as it's the only way to get decent performance from resolvers but high
variance in response time,
and request semantics in both is different and needs to be defined,
i.e. what happens when client cancels
in-flight query, what happens when server resolver pushes response.

Marek


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

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


Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

2016-07-11 Thread John Levine
>So I suggest some thought should be given to reducing round-trips by 
>allowing for multiple DNS request payloads in a single HTTP request 
>message, and multiple DNS response payloads in an HTTP response message.

Don't you get this automatically if it's treated as a TCP DNS
connection?  You stuff a bunch of requests down the pipe, and you get
back a bunch of responses.

See RFC 7766.

R's
John

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

2016-07-11 Thread 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] Call for Adoption: draft-song-dns-wireformat-http

2016-07-11 Thread Adrien de Croy


One thing I think has always been bugging me about DNS over HTTP is the 
appalling performance we will likely see in a lot of cases.  Even small 
latencies in normal DNS lookups cause major impact on page load times on 
complex pages with resources from many servers, and adding HTTP overhead 
to this will slow things further.


So I suggest some thought should be given to reducing round-trips by 
allowing for multiple DNS request payloads in a single HTTP request 
message, and multiple DNS response payloads in an HTTP response message.


E.g. sending requests as base64 encoded blob values in key-value pairs 
as post data, so that a response can be linked back to the request.


At this stage of the game this should be quite easy, but will become 
more and more difficult as time goes by if the single request/response 
model is rolled out.


Regards

Adrien

-- Original Message --
From: "Tim Wicinski" 
To: "dnsop" 
Sent: 12/07/2016 10:33:14 a.m.
Subject: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http


This starts an official Call for Adoption for
  draft-song-dns-wireformat-http

The draft is available here:
https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/

Please review this draft to see if you think it is suitable for 
adoption by DNSOP, and comments to the list, clearly stating your view.


Please also indicate if you are willing to contribute text, review, 
etc.


We wanted this Call to coincide with the Berlin meeting so if there is 
opinions that needed to be voiced, they can do so.


This call for adoption ends: 25 July 2016

Thanks,
tim wicinski
DNSOP co-chair

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


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


Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

2016-07-11 Thread John Levine
>Please review this draft to see if you think it is suitable for adoption 
>by DNSOP, and comments to the list, clearly stating your view.

Yes, we should adopt it.  It needs some work, but what draft doesn't.

>Please also indicate if you are willing to contribute text, review, etc.

Yes.

My main suggestion is to lose the Proxy-DNS-Transport header and
always have the request and response in TCP format.  If the server
doing the http-to-DNS proxy wants to microoptimize and try the query
as UDP and see if it works, that's fine, but I'm guessing that the
proxy will usually be close to the cache it's using so the penalty for
TCP will be low.

I'd also want to change some of the motivation text.  To me, by far
the most likely scenario here is javascript applications that want to
do DNS queries, e.g. for SRV, but can't because javascript doesn't let
you do that.  Now the server that provided the javascript blob can
also be the DNS proxy.  The javascript can't query random other DNS
proxies due to cross-site scripting rules.

R's,
John

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


[DNSOP] The DNSOP WG has placed draft-bellis-dnsop-session-signal in state "Candidate for WG Adoption"

2016-07-11 Thread IETF Secretariat

The DNSOP WG has placed draft-bellis-dnsop-session-signal in state 
Candidate for WG Adoption (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/

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


[DNSOP] Call for Adoption: draft-song-dns-wireformat-http

2016-07-11 Thread Tim Wicinski

This starts an official Call for Adoption for
 draft-song-dns-wireformat-http

The draft is available here:
https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/

Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.


Please also indicate if you are willing to contribute text, review, etc.

We wanted this Call to coincide with the Berlin meeting so if there is 
opinions that needed to be voiced, they can do so.


This call for adoption ends: 25 July 2016

Thanks,
tim wicinski
DNSOP co-chair

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


Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

2016-07-11 Thread George Michaelson
UDP+cookies could work for you?

-G

On Mon, Jul 11, 2016 at 10:19 PM, Ray Bellis  wrote:
>
>
> On 11/07/2016 07:13, George Michaelson wrote:
>
>> Things like client capability signalling, I suspect are in a harder
>> bucket. I won't say intractably hard, but last time I floated
>> capability flagging, I got pretty strong pushback.
>
> I think capability flagging is difficult in a stateless protocol like
> UDP - there's no guarantee that the next endpoint that you send a packet
> to is the same one that just told you what capabilities it has.
>
> It could be done over TCP, and perhaps in other protocols that add a
> pseudo-session on top of UDP (e.g. DNS-o-DTLS?) but even then the
> signaling should only really apply to the current connection / session.
>
> As it happens, the Session Signaling draft I submitted last week
> originally had an option for exchanging the end-points' EDNS0 option
> support, but some of my co-authors didn't like it so I removed it...
>
> Ray
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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


Re: [DNSOP] draft-wkumari-dnsop-multiple-responses-03

2016-07-11 Thread Warren Kumari
On Mon, Jul 11, 2016 at 10:01 AM, John Dickinson  wrote:
> Hi,
>
> A couple of nits
>
> EXTRA is spelt in at least 3 different ways.

Yup. English is an evolving language -- it was just evolving faster in
this doc than elsewhere :-)
Fixed in Github version (to be posted once the draft cutoff opens):
https://github.com/wkumari/draft-wkumari-dnsop-multiple-responses



> The example in 5.1 introduces the AAA RR type without definition :)
>

Gah, I thought I could slide that though, and not have to write a
whole new draft.
Fixed...


> Section 2 paragraph 1: I think that more recent examples of the background 
> regarding trust of additional records could be found.


Yes, so would I / we -- however, we spent some time looking
(specifically on the "why not to trust additional") and were not able
to find any. Any pointers much appreciated.

> IMHO section 8 item 2 should be removed as it is tending towards saying how 
> item 3 should be implemented.

Fair 'nuff. Done, and updated in Github.

Thank you for your comments. See you in Berlin?
W

>
> regards
> John
>
>
> John Dickinson
>
> http://sinodun.com
>
> Sinodun Internet Technologies Ltd.
> Magdalen Centre
> Oxford Science Park
> Robert Robinson Avenue
> Oxford OX4 4GA
> U.K.
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> 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

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

2016-07-11 Thread 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"

2016-07-11 Thread 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"

2016-07-11 Thread 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] I-D Action: draft-ietf-dnsop-terminology-bis-01.txt

2016-07-11 Thread Bob Harold
On Fri, Jul 8, 2016 at 5:20 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
>
> Title   : DNS Terminology
> Authors : Paul Hoffman
>   Andrew Sullivan
>   Kazunori Fujiwara
> Filename: draft-ietf-dnsop-terminology-bis-01.txt
> Pages   : 30
> Date: 2016-07-08
>
> Abstract:
>The DNS is defined in literally dozens of different RFCs.  The
>terminology used by implementers and developers of DNS protocols, and
>by operators of DNS systems, has sometimes changed in the decades
>since the DNS was first defined.  This document gives current
>definitions for many of the terms used in the DNS in a single
>document.
>
>This document will be the successor to RFC 7719.  It will update many
>of the original RFCs.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-01
>
>
 Source of Synthesis
">asterisk label<.>closest encloser<." should be ".."

Page 21
"The oginal defintion of SEPs was in [RFC3757]." should be "The original
definition of SEPs was in [RFC3757]."
(spelling correction of "original definition")

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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-02.txt

2016-07-11 Thread Bob Harold
On Fri, Jul 8, 2016 at 6:36 PM, Paul Hoffman  wrote:

> Greetings again; I'm the new co-author on this draft. Based on the WG
> discussion where a bunch of us wanted to use EDNS0 and a bunch of us wanted
> to use queries, the authors tentatively decided that the best way to go
> forwards is to put both methods in the draft. After all, a motivated
> observer of the signals will not have much problem watching both types of
> signals, and end systems can decide which of the two they want to use.
>
> We understand that "specify more than one" is often an unpopular choice in
> the IETF, about as unpopular as "don't get consensus on one". This is a WG
> document so we need consensus even to go with two ways. We look forward to
> hearing from you about this choice and how we can move forwards.
>
> --Paul Hoffman
>
>
>
> On 8 Jul 2016, at 15:30, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Domain Name System Operations of the
>> IETF.
>>
>> Title   : Signaling Trust Anchor Knowledge in DNS
>> Security Extensions (DNSSEC)
>> Authors : Duane Wessels
>>   Warren Kumari
>>   Paul Hoffman
>> Filename: draft-ietf-dnsop-edns-key-tag-02.txt
>> Pages   : 13
>> Date: 2016-07-08
>>
>> Abstract:
>>The DNS Security Extensions (DNSSEC) were developed to provide origin
>>authentication and integrity protection for DNS data by using digital
>>signatures.  These digital signatures can be verified by building a
>>chain-of-trust starting from a trust anchor and proceeding down to a
>>particular node in the DNS.  This document specifies two different
>>ways for validating resolvers to signal to a server which keys are
>>referenced in their chain-of-trust.  The data from such signaling
>>allow zone administrators to monitor the progress of rollovers in a
>>DNSSEC-signed zone.
>>
>>This document describes two independent methods for validating
>>resolvers to publish their referenced keys: an EDNS option and a
>>differnt DNS query.  The reason there are two methods instead of one
>>is some people see significant problems with each method.  Having two
>>methods is clearly worse than having just one, but it is probably
>>better for the Internet than having no way to gain the information
>>from the resolvers.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-edns-key-tag-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-key-tag-02
>>
>>
Abstract, second paragraph
"differnt" -> "different"

5.1. Query Format
What if the key tag is less than 0x1000 hex or 4096 decimal - Should the
resulting hex have leading zeros (always 4 characters?) or not?
For example, would 4095 decimal be _ta-0fff or _ta-fff  ?  (I prefer always
4 characters hex, but it is your doc.)

5.3.1. Interaction With Aggressive Negative Caching
I would prefer that the tags always be sorted.  No big deal for two tags,
but if there was a compromise or mistake during a rollover, there might be
three keys and the savings in records might be significant.  If you decide
to specify sorting, I think it would go in section 5.1 and not in 5.3.1.

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


[DNSOP] draft-wkumari-dnsop-multiple-responses-03

2016-07-11 Thread John Dickinson
Hi,

A couple of nits

EXTRA is spelt in at least 3 different ways.
The example in 5.1 introduces the AAA RR type without definition :)

Section 2 paragraph 1: I think that more recent examples of the background 
regarding trust of additional records could be found.
IMHO section 8 item 2 should be removed as it is tending towards saying how 
item 3 should be implemented.

regards
John


John Dickinson

http://sinodun.com

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.

signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

2016-07-11 Thread Ray Bellis


On 11/07/2016 07:13, George Michaelson wrote:

> Things like client capability signalling, I suspect are in a harder
> bucket. I won't say intractably hard, but last time I floated
> capability flagging, I got pretty strong pushback.

I think capability flagging is difficult in a stateless protocol like
UDP - there's no guarantee that the next endpoint that you send a packet
to is the same one that just told you what capabilities it has.

It could be done over TCP, and perhaps in other protocols that add a
pseudo-session on top of UDP (e.g. DNS-o-DTLS?) but even then the
signaling should only really apply to the current connection / session.

As it happens, the Session Signaling draft I submitted last week
originally had an option for exchanging the end-points' EDNS0 option
support, but some of my co-authors didn't like it so I removed it...

Ray

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


Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

2016-07-11 Thread George Michaelson
Thats good to know Mark. I took a dark view of change in DNS, but I do
recall believing that for some problems, with tractable volumes of
change-effectors, you can move on them. So, thanks for pushing: it
helps.

Things like client capability signalling, I suspect are in a harder
bucket. I won't say intractably hard, but last time I floated
capability flagging, I got pretty strong pushback.

-G

On Mon, Jul 11, 2016 at 3:58 PM, Mark Andrews  wrote:
>
> In message 
>