Flattered to be mentioned. Specially thanks to Geoff and Joao for their
effort to demontrate ATR with measurement and facts. You did what I desired
but failed to do.
If you think ATR is worth of doing, I'm looking forward to more comments to
improve it towards a formal document.
-Davey
On 22 Marc
> On 23 Mar 2018, at 11:55 am, Mark Andrews wrote:
>
> This title of this document DOES NOT match reality.
>
> "A Sentinel for Detecting Trusted Keys in DNSSEC” should be
> replaced by “A Root Key Trust Anchor Sentinel for DNSSEC”.
>
> kskroll-sentinel-- really needs something other
> than “ks
> On 22 Mar 2018, at 10:30 pm, Ralph Dolmans wrote:
>
> Hi,
>
> On 21-03-18 16:58, Petr Špaček wrote:
>> draft-spacek-edns-camel-diet-00 is a new draft which partially reacts to
>> The Camel talk from yesterday, and is based on plan of open-source DNS
>> software vendors to get rid of EDNS work
This title of this document DOES NOT match reality.
"A Sentinel for Detecting Trusted Keys in DNSSEC” should be
replaced by “A Root Key Trust Anchor Sentinel for DNSSEC”.
kskroll-sentinel-- really needs something other
than “kskroll” as the first field. “root-key-sentinal--”
really more clearly
On 3/22/2018 2:41 PM, Ray Bellis wrote:
- the table formatting is pretty poor, do we really need any more
than just "NAME", "RR" and "REFERENCE"? The ID field just seems
to be an alternate mnemonic for the (already unique) underscore
label itself
I've looked over the latest version o
On 3/22/2018 2:41 PM, Ray Bellis wrote:
Dave,
I think this is much improved :)
A few nits:
Each globally-registered underscore name owns a distinct, subordinate
name space.
except when it doesn't (i.e. the SRV transports all share the *same*
subordinate name space).
Well, ummm, I think th
Hi everyone,
I did a small writeup of the "DNS Camel" presentation from this Tuesday in
London.
It can be found here:
https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/
(includes link to video,
https://www.youtube.com/watch?v=8N_PO3s_Z24&feature=youtu.be&t=1h20m4s
Dave,
I think this is much improved :)
A few nits:
> Each globally-registered underscore name owns a distinct, subordinate
> name space.
except when it doesn't (i.e. the SRV transports all share the *same*
subordinate name space).
- on that note, _sctp and _dccp are missing from the global tab
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 WG of the IETF.
Title : DNS Scoped Data Through '_Underscore' Naming of
Attribute Leaves
Author : Dave Crocker
On Thu, Mar 22, 2018 at 05:47:58PM +, Ondřej Surý wrote:
...
> > They should switch away from SHA1 as SHA1 is being deprecated industry
> > wide. Even if we recommend to move away from RSA (which I'm not sure if
> > there
> > is consensus on) to ECC, I would like to move them to ED25519/ED448
--
Ondřej Surý
ond...@isc.org
> On 22 Mar 2018, at 17:27, Paul Wouters wrote:
>
> On Thu, 22 Mar 2018, Ondřej Surý wrote:
>
>> https://github.com/oerdnj/draft-ietf-dnsop-algorithm-update
>>
>> Pull/Merge Requests, Issues, etc. are welcome.
>>
>> The most of the work done between the last ver
On Thu, 22 Mar 2018, Ondřej Surý wrote:
https://github.com/oerdnj/draft-ietf-dnsop-algorithm-update
Pull/Merge Requests, Issues, etc. are welcome.
The most of the work done between the last version and this is:
* Removal of MUST-, SHOULD+, etc…
* Upgrade the urgency of deploying ECC
* Separat
Bob Harold wrote:
...
Unfortunately, the resolver needs to make decisions based on the
original transport, for example if the transport is TCP, it can send any
size response. But if UDP, it needs to fit in a smaller size, and it
often sends less info in the response. Likewise, session signa
On Thu, Mar 22, 2018 at 12:42 PM, Dave Lawrence wrote:
> Davey Song writes:
> > To keep the transparency of DOH proxy, the proxy server should use
> > the same transport as the proxy client receive queries from
> > stub-resolver, transports patterns like UDP-DOH-UDP, and
> > TCP-DOH-TCP. So the p
Dave Lawrence wrote:
I'm really not digging this as a good use of a media type, especially
when the draft says:
...
nor i. apparently there were only worse choices, in the eyes of http folks.
So, dns-tcpwireformat and dns-udpwireformat are byte-for-byte
identical on the wire, and you're ju
On 22/03/2018 15:12, Dave Crocker wrote:
> In the case of SRV, for example, that means that for the core SRV
> template specification document:
>
> 1. The first-level, _Proto name assignment text has to be updated
> to use the new, Attrleaf global table.
>
> 2. The second-level _Servic
Davey Song writes:
> To keep the transparency of DOH proxy, the proxy server should use
> the same transport as the proxy client receive queries from
> stub-resolver, transports patterns like UDP-DOH-UDP, and
> TCP-DOH-TCP. So the proxy client should signal the proxy server the
> initial transport
On 3/20/2018 9:31 AM, John R. Levine wrote:
2. SRV and URI
These need more detailed text, very much in the s/old/new style.
The current text in them does a use-by-reference of existing tables
defined for other purposes. The Update text will, instead, specify a
requirement for adding entr
Hi,
Tim has poked me and Paul W. that WG have actually accepted Algorithm
Implementation Requirements and Usage Guidance for DNSSEC as a working group
document.
I have updated the draft and submitted is as a WG document and meanwhile it
sits there patiently for WG chair approval, you can look
Thanks for your advice.
Davey
Bob Harold 于 2018年3月22日周四 22:41写道：
>
> On Wed, Mar 21, 2018 at 9:36 PM, Davey Song wrote:
>
>> Hi folks,
>>
>> I just submit a updated version of dns wireformat over HTTP. This draft
>> has been adopted as the dnsop wg document for quite a while before DOH.
>> The
On Wed, Mar 21, 2018 at 9:36 PM, Davey Song wrote:
> Hi folks,
>
> I just submit a updated version of dns wireformat over HTTP. This draft
> has been adopted as the dnsop wg document for quite a while before DOH.
> The original intention of this draft is to explore the possiblity of DNS
> over HT
I agree, model 1 and model 2 seems doable. Note that RFC 6781 has some
text for model 2 on rollover when changing DNS operators.
https://tools.ietf.org/html/rfc6781#section-4.3.5
Matthijs
On 22-03-18 13:50, Tony Finch wrote:
Olafur Gudmundsson wrote:
I think only Model #1 makes sense, i.e
On Thu, Mar 22, 2018 at 1:42 PM, Tony Finch wrote:
> Shumon Huque wrote:
> > On Thu, Mar 22, 2018 at 12:50 PM, Tony Finch wrote:
> > >
> > > From the provider point of view, I think there are a couple of models:
> > >
> > > (a) provider has KSK and ZSK; zone owner needs to be able to import
> o
Shumon Huque wrote:
> On Thu, Mar 22, 2018 at 12:50 PM, Tony Finch wrote:
> >
> > From the provider point of view, I think there are a couple of models:
> >
> > (a) provider has KSK and ZSK; zone owner needs to be able to import other
> > provider public keys into this provider's DNSKEY RRset, an
On Thu, Mar 22, 2018 at 1:00 PM, Shumon Huque wrote:
> On Thu, Mar 22, 2018 at 12:50 PM, Tony Finch wrote:
>
>> Olafur Gudmundsson wrote:
>> >
>> > I think only Model #1 makes sense, i.e Zone apex DNSKEY/CDNSKEY/CDS
>> > RRset's are signed by zone publisher but rest signed by operator on the
>>
On Thu, Mar 22, 2018 at 12:50 PM, Tony Finch wrote:
> Olafur Gudmundsson wrote:
> >
> > I think only Model #1 makes sense, i.e Zone apex DNSKEY/CDNSKEY/CDS
> > RRset's are signed by zone publisher but rest signed by operator on the
> > fly.
>
> From the provider point of view, I think there are
Olafur Gudmundsson wrote:
>
> I think only Model #1 makes sense, i.e Zone apex DNSKEY/CDNSKEY/CDS
> RRset's are signed by zone publisher but rest signed by operator on the
> fly.
>From the provider point of view, I think there are a couple of models:
(a) provider has KSK and ZSK; zone owner need
Tony Finch wrote:
>
> Here are some sketchy notes on what this might say...
Geoff Huston just told me I need to read Davey Song's very clever
"additional truncated response" and that he would roast my suggestions
if I didn't mention ATR :-)
https://tools.ietf.org/html/draft-song-atr-large-resp
ht
On Thu, 22 Mar 2018, Olafur Gudmundsson wrote:
The document covers the case that different providers use different signing
algorithms BUT does not cover if they use different negative
answer approaches,
no good answer other than say NSEC with “lies”.
I think the document describes what I th
Hi,
On 21-03-18 16:58, Petr Špaček wrote:
> draft-spacek-edns-camel-diet-00 is a new draft which partially reacts to
> The Camel talk from yesterday, and is based on plan of open-source DNS
> software vendors to get rid of EDNS workarounds.
>From the introduction:
> EDNS version 0 was standardiz
To keep the transparency of DOH proxy, the proxy server should use the same
transport as the proxy client receive queries from stub-resolver,
transports patterns like UDP-DOH-UDP, and TCP-DOH-TCP. So the proxy client
should signal the proxy server the initial transport recieve from
stub-client.
Da
On Wed, Mar 21, 2018 at 08:17:08PM -0400, Matthew Pounsett wrote:
> Congratulations on an extremely short, to the point draft. I think that's
> the shortest I've ever read.
Indeed! I hesitate to offer trivial rephrasing suggestions because it
might represent such a significant percentage of the f
Davey Song writes:
> Is a media type "application/dns-tcpwireformat" acceptable
Without yet having (re-)read the draft, I'm unclear on what benefit
this media type is bringing over dns-udpwireformat, since the only
difference presumably is explicitly adding the two octets of a
content-length <= 65
Hi all,
As you probably saw from Tim’s email overnight, he’s injured his knee and his
priority today is getting medical attention for it. But Session II is under
control and we’ll convene at 18:10-19:10 this evening in the Sandringham room,
with a proxy Tim if needed.
We do still need a jabber
34 matches
Mail list logo
