Re: [DNSOP] DNSOP Digest, Vol 122, Issue 9

On 06/01/2017 22:20, Richard Gibson wrote: > Why not use Address Family like EDNS Client Subnet Robert Edmonds and I already had that discussion off-list :) This option isn't intended to carry transport addresses that a DNS server couldn't already handle for itself. As it is, ECS only allows

Re: [DNSOP] DNSOP Digest, Vol 122, Issue 9

On Fri, 6 Jan 2017 13:01:10 -0500, Robert Edmonds wrote: > It can be rev'd in the same document that introduces a DNS address RR > for that address family :-) > Why not use Address Family

[DNSOP] Call For Presentations - DNS-OARC Workship 26, Madrid, 14-15 May 2017

[with apologies to those who see this on multiple lists] Call For Presentations The DNS-OARC 26th Workshop will take place in Madrid, Spain on May 14th and 15th 2017, the Sunday and Monday following the ICANN GDD Industry Summit 2017. The Workshop's Program Committee is now requesting proposals

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt

On 06/01/2017 18:43, Wessels, Duane wrote: > Hi Ray, > > The idea of "X-Forwarded-For" for DNS makes me nervous, but it is > probably inevitable. > > It is of course quite similar to EDNS client subnet, except that > there is no masking and the client cannot opt-out. Might be worth > saying in

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt

On Fri, Jan 06, 2017 at 06:43:30PM +, Wessels, Duane wrote: > When a server receives the option from a non-whitelisted client, it > MUST return a FORMERR response. +1 -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP

[DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-02.txt

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 catalog zones Authors : Mukund Sivaraman Stephen Morris

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt

For folk wondering what Ray is referring to below, I posted this to the DPRIVE (dns-privacy@) list last night. I was originally going to CC dnsop@ but cross-posting leads to many "your message could not be delivered, you aren't subscribed" errors. The obvious, bestest solution would just be for

Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt

Hi Tim On Fri, Jan 06, 2017 at 02:00:39PM -0500, tjw ietf wrote: > Mukund, > > While I agree with you, Joel has the right guidance on this; but also > knowing the authors fairly well, > I feel they would not send us down a road that will box the work into a > corner. Yes, it was not in any way

Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt

Mukund, While I agree with you, Joel has the right guidance on this; but also knowing the authors fairly well, I feel they would not send us down a road that will box the work into a corner. On Fri, Jan 6, 2017 at 1:25 PM, Mukund Sivaraman wrote: > On Fri, Jan 06, 2017 at

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt

> On Jan 6, 2017, at 6:49 AM, Ray Bellis wrote: > > Spurred on by Warren's announcement of a Docker image that uses NGINX to > proxy TLS connections into DNS servers that don't natively support TLS, > I've just written up this short draft describing an EDNS0 option that > allows

Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt

On Fri, Jan 06, 2017 at 09:47:41AM -0800, joel jaeggli wrote: > On 1/6/17 9:25 AM, Mukund Sivaraman wrote: > > On Fri, Jan 06, 2017 at 01:48:59AM +, Warren Kumari wrote: > >>> (2) In a feature implemented for Unbound: > >>> > >>> - Unbound first checks cache > >>> > >>> - If a stale answer is

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt

On 06/01/2017 18:01, Robert Edmonds wrote: > It can be rev'd in the same document that introduces a DNS address RR > for that address family :-) Fair enough! I'll rely on you to remind me when the time comes ;-) Ray ___ DNSOP mailing list

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt

Ray Bellis wrote: > Yes, that seems like a reasonable suggestion, although it would be a > shame to have to rev the doc if another IP version should even happen to > be introduced in the future... It can be rev'd in the same document that introduces a DNS address RR for that address family :-)

Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt

On 1/6/17 9:25 AM, Mukund Sivaraman wrote: > On Fri, Jan 06, 2017 at 01:48:59AM +, Warren Kumari wrote: >>> (2) In a feature implemented for Unbound: >>> >>> - Unbound first checks cache >>> >>> - If a stale answer is found, its TTL is set to 0, and the cache entry >>> is served >>> >>> - If

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt

On 06/01/2017 17:28, Robert Edmonds wrote: > Hi, Ray: > > The values used by the "IP Version" field should be specified: > >IP Version: The IP protocol version number used by the client. > > Since the field is 4 bits long I would guess this field happens to be > the same as the version

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt

Ray Bellis wrote: > Spurred on by Warren's announcement of a Docker image that uses NGINX to > proxy TLS connections into DNS servers that don't natively support TLS, > I've just written up this short draft describing an EDNS0 option that > allows smart proxies to tell the backend server what the

Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt

On Fri, Jan 06, 2017 at 01:48:59AM +, Warren Kumari wrote: > > (2) In a feature implemented for Unbound: > > > > - Unbound first checks cache > > > > - If a stale answer is found, its TTL is set to 0, and the cache entry > > is served > > > > - If a stale answer is found, Unbound starts

[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt

Spurred on by Warren's announcement of a Docker image that uses NGINX to proxy TLS connections into DNS servers that don't natively support TLS, I've just written up this short draft describing an EDNS0 option that allows smart proxies to tell the backend server what the original client IP address