Re: [DNSOP] Privacy and DNSSEC

2020-04-24 Thread Paul Vixie
mind if i cut in? On Saturday, 25 April 2020 06:23:54 UTC Vladimír Čunát wrote: > Original subject: New draft on delegation revalidation > > On 4/24/20 4:49 PM, Shumon Huque wrote: > > ... > > ... (agreeableness.) > Still, note that for some consumers the secure transport may be an > argument

Re: [DNSOP] Privacy and DNSSEC

2020-04-24 Thread Vladimír Čunát
Original subject: New draft on delegation revalidation On 4/24/20 4:49 PM, Shumon Huque wrote: > > Even DNSSEC-validated NSs and IPs aren't sufficient to ensure privacy, > so I'd rather kill this problem by proper encrypted protocol towards > authoritatives (in current dprive charter).

Re: [DNSOP] New draft on delegation revalidation

2020-04-24 Thread Shumon Huque
On Thu, Apr 23, 2020 at 7:29 AM Giovane C. M. Moura wrote: > Hi Shumon, > > > The main recommendations in the draft are to: (1) deterministically > > prefer the authoritative child NS set over the non-authoritative, > > unsigned, delegating NS set in the parent > > This was a problem waiting to b

Re: [DNSOP] New draft on delegation revalidation

2020-04-24 Thread Shumon Huque
On Fri, Apr 24, 2020 at 6:21 PM Gavin McCullagh wrote: > > >> [a] seems like a definition which could be changed if it was so decided. >>> DS records are totally parent centric for example. It seems like NS could >>> be too if we declared the in-zone NS to be "informational only". [...] >>> >>

Re: [DNSOP] New draft on delegation revalidation

2020-04-24 Thread Gavin McCullagh
Hi Shumon, On Wed, Apr 22, 2020 at 12:32 PM Shumon Huque wrote: But appreciating the subtleties of the DNS delegation mechanism involves a > lot of arcane details that are not easy to understand for anyone. If the > namespace is a tree, and zones are contiguous subtrees, how do you a > visualize

[DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-extended-error-15: (with COMMENT)

2020-04-24 Thread Éric Vyncke via Datatracker
Éric Vyncke has entered the following ballot position for draft-ietf-dnsop-extended-error-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-extended-error-15: (with COMMENT)

2020-04-24 Thread Benjamin Kaduk via Datatracker
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-extended-error-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please ref

[DNSOP] I-D Action: draft-ietf-dnsop-extended-error-15.txt

2020-04-24 Thread internet-drafts
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 : Extended DNS Errors Authors : Warren Kumari Evan Hunt

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-extended-error-14: (with DISCUSS and COMMENT)

2020-04-24 Thread Warren Kumari
On Fri, Apr 24, 2020 at 11:17 AM Vittorio Bertola wrote: > > > > > Il 23/04/2020 20:14 Warren Kumari ha scritto: > > > > On Thu, Apr 23, 2020 at 5:04 AM Vittorio Bertola > > wrote: > > > > > > Indeed, thinking at the possible use case for those error codes, it would > > > make sense for the for

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-extended-error-14: (with DISCUSS and COMMENT)

2020-04-24 Thread Vittorio Bertola
> Il 23/04/2020 20:14 Warren Kumari ha scritto: > > On Thu, Apr 23, 2020 at 5:04 AM Vittorio Bertola > wrote: > > > > Indeed, thinking at the possible use case for those error codes, it would > > make sense for the forwarder to forward them to the final user. Perhaps we > > can fix the lan

Re: [DNSOP] New draft on delegation revalidation

2020-04-24 Thread Shumon Huque
On Thu, Apr 23, 2020 at 7:09 AM Vladimír Čunát wrote: > On 4/22/20 9:32 PM, Shumon Huque wrote: > > Since delegation records and glue address records are unsigned, they > > can be spoofed, and DNSSEC should really allow us to detect such > > spoofing once a resolver sees referral data. > > I woul