Re: [DNSOP] New draft on delegation revalidation

On Saturday, 30 May 2020 17:13:10 UTC Gavin McCullagh wrote: > ... > > I think Petr's point might be that someone could interpret the draft > (perhaps especially the simple mechanism) to mean that the NS TTL becomes > an effective cap on the TTL of all records below the zone cut even where > the

Re: [DNSOP] New draft on delegation revalidation

On Sat, May 30, 2020 at 1:13 PM Gavin McCullagh wrote: > Hi, > > On Thu, May 28, 2020 at 8:56 AM Paul Vixie wrote: > >> On Thursday, 28 May 2020 14:38:11 UTC Petr Špaček wrote: >> > On 25. 05. 20 5:23, Shumon Huque wrote: >> > > ... >> > > Most importantly: >> > > - Does the NS affect

Re: [DNSOP] New draft on delegation revalidation

Hi, On Thu, May 28, 2020 at 8:56 AM Paul Vixie wrote: > On Thursday, 28 May 2020 14:38:11 UTC Petr Špaček wrote: > > On 25. 05. 20 5:23, Shumon Huque wrote: > > > ... > > > Most importantly: > > > - Does the NS affect maximum TTL of _other_ data in the zone? > > > > > > I think there

Re: [DNSOP] New draft on delegation revalidation

On Thursday, 28 May 2020 14:38:11 UTC Petr Špaček wrote: > On 25. 05. 20 5:23, Shumon Huque wrote: > > ... > > Most importantly: > > - Does the NS affect maximum TTL of _other_ data in the zone? > > > > I think there are probably different views on what should happen here. > > Folks who

Re: [DNSOP] New draft on delegation revalidation

On 25. 05. 20 5:23, Shumon Huque wrote: > On Thu, May 21, 2020 at 8:24 AM Petr Špaček > wrote: > > > > >    https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 > > I would appreciate a practical example of changes envisioned in the >

Re: [DNSOP] New draft on delegation revalidation

Hi Shumon, > Thanks Giovane (and Marco)! Sure thing. > The HTTPS site goes to a different and mostly empty page - and > Chrome doesn't like the certificate because it has a wildcard Subject > CN. Are you planning to fix that? fixed. > I know DNSSEC is likely not the focus of your experiment,

Re: [DNSOP] New draft on delegation revalidation

On Thu, May 21, 2020 at 8:24 AM Petr Špaček wrote: > > > >https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 > > I would appreciate a practical example of changes envisioned in the > following paragraph: > > >A common reason that zone owners want to ensure that resolvers

Re: [DNSOP] New draft on delegation revalidation

On 10. 04. 20 15:45, Shumon Huque wrote: > Hi folks, > > Paul Vixie, Ralph Dolmans, and I have submitted this I-D for > consideration: > >    https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 I would appreciate a practical example of changes envisioned in the following

Re: [DNSOP] New draft on delegation revalidation

On Mon, May 11, 2020 at 9:00 AM Giovane C. M. Moura wrote: > > >> Do you plan to maintain the parent/child disjoint NS > >> domain (marigliano.xyz ) going forward? And what > >> about the test > >> domains for other types of misconfigurations? > > > > Great idea. Let me

Re: [DNSOP] New draft on delegation revalidation

>> Do you plan to maintain the parent/child disjoint NS  >> domain (marigliano.xyz ) going forward? And what >> about the test >> domains for other types of misconfigurations? > > Great idea. Let me look into this, will get back to with that. Done. Check

Re: [DNSOP] New draft on delegation revalidation

Thanks, that will be appreciated. I will make sure the two documents are synchronised. Yours, Daniel On Mon, May 4, 2020 at 8:20 AM Shumon Huque wrote: > On Wed, Apr 29, 2020 at 11:57 AM Daniel Migault > wrote: > >> Hi, >> >> I discovered this draft during the interim meeting. We had similar

Re: [DNSOP] New draft on delegation revalidation

On Wed, Apr 29, 2020 at 11:57 AM Daniel Migault wrote: > Hi, > > I discovered this draft during the interim meeting. We had similar > thoughts in our "Recommendations for DNSSEC Resolvers Operators". Our > motivation for supporting this work are that it 1) improves the > reliability of the

Re: [DNSOP] New draft on delegation revalidation

> I meant servers within the child (or parent) NS set had different NS > sets configured in them, i.e. yet another level of mismatch. Maybe > that's not worth investigating, but I'm pretty sure I've come across > such misconfigurations in the past. Oh now I get it. We did only with a sample of

Re: [DNSOP] New draft on delegation revalidation

Hi, I discovered this draft during the interim meeting. We had similar thoughts in our "Recommendations for DNSSEC Resolvers Operators". Our motivation for supporting this work are that it 1) improves the reliability of the resolution as well as 2) removes the temptation to (inadvertently) break

Re: [DNSOP] New draft on delegation revalidation

On Tue, Apr 28, 2020 at 5:43 AM Giovane C. M. Moura wrote: > Hi Shumon, > > > Do you plan to maintain the parent/child disjoint NS > > domain (marigliano.xyz ) going forward? And what > > about the test > > domains for other types of misconfigurations? > > Great idea. Let

Re: [DNSOP] New draft on delegation revalidation

Hi Shumon, > Do you plan to maintain the parent/child disjoint NS  > domain (marigliano.xyz ) going forward? And what > about the test > domains for other types of misconfigurations? Great idea. Let me look into this, will get back to with that. > Did you look at the

Re: [DNSOP] New draft on delegation revalidation

On Mon, Apr 27, 2020 at 8:09 AM Joe Abley wrote: > On 25 Apr 2020, at 00:30, Shumon Huque wrote: > > On Fri, Apr 24, 2020 at 6:21 PM Gavin McCullagh > wrote > > That's one way to approach it. What I was thinking was, if the >> registries want to dictate the TTL, that seems understandable.

Re: [DNSOP] New draft on delegation revalidation

On Fri, Apr 24, 2020 at 6:21 PM Gavin McCullagh wrote: > ... > PS How truly intractible is the registry argument? It seems something > like "When an NS change is made, TTL=3600 for the first N hours, then 2 > days thereafter." would be a major step forward without drastically > increasing

Re: [DNSOP] New draft on delegation revalidation

On 25 Apr 2020, at 00:30, Shumon Huque wrote: > On Fri, Apr 24, 2020 at 6:21 PM Gavin McCullagh > wrote: > > PS How truly intractible is the registry argument? It seems something like > "When an NS change is made, TTL=3600 for the first N hours, then 2 days >

Re: [DNSOP] New draft on delegation revalidation

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

Re: [DNSOP] New draft on delegation revalidation

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

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 >

Re: [DNSOP] New draft on delegation revalidation

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

Re: [DNSOP] New draft on delegation revalidation

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 be addressed for a long time. Thanks for writing this. For what is

Re: [DNSOP] New draft on delegation revalidation

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 wouldn't put much energy into improving this part in *this* draft. 

Re: [DNSOP] New draft on delegation revalidation

On 22 Apr 2020, at 18:30, Shumon Huque wrote: > Nice! > > You didn't name the entity/company, so I won't ask. But I am mildly > curious about why they never brought the proposal to the regext > working group. Others will surely have greater insight, but there is much work on the

Re: [DNSOP] New draft on delegation revalidation

Nice! You didn't name the entity/company, so I won't ask. But I am mildly curious about why they never brought the proposal to the regext working group. Shumon. On Wed, Apr 22, 2020 at 5:24 PM Patrick Mevzek wrote: > On 22/04/2020 16:01, Shumon Huque wrote: > > Yeah, that was what I thought.

Re: [DNSOP] New draft on delegation revalidation

On 22/04/2020 16:01, Shumon Huque wrote: > Yeah, that was what I thought. I just wasn't sure whether some EPP TTL > setting extension had been proposed or developed. There is in fact at least one to my knowledge :-) It allows to add that payload to a domain create: 300 To do

Re: [DNSOP] New draft on delegation revalidation

On Wed, Apr 22, 2020 at 4:48 PM Patrick Mevzek wrote: > On 22/04/2020 14:32, Shumon Huque wrote: > > Based on history to date, it seems to be rather intractable, but I would > > love to be proven wrong. The interfaces that registrars use to update > > delegation records in the registries don't

Re: [DNSOP] New draft on delegation revalidation

On 22/04/2020 14:32, Shumon Huque wrote: > Based on history to date, it seems to be rather intractable, but I would > love to be proven wrong. The interfaces that registrars use to update > delegation records in the registries don't even offer any TTL > configuration option that I've seen (even if

Re: [DNSOP] New draft on delegation revalidation

On Mon, Apr 20, 2020 at 1:27 PM Gavin McCullagh wrote: > Hi, > > I'm new to posting on this list, so please accept my advance apologies if > I make any novice errors or posted this in the wrong place. Apologies also > for the long email. :-) > Hi Gavin, and welcome to DNSOP! :) Thanks for your

Re: [DNSOP] New draft on delegation revalidation

Hi, I'm new to posting on this list, so please accept my advance apologies if I make any novice errors or posted this in the wrong place. Apologies also for the long email. :-) I can't claim to have the same detailed knowledge of the protocol as the authors of this draft. All the same, I've

Re: [DNSOP] New draft on delegation revalidation

On Mon, Apr 13, 2020 at 4:59 PM Shumon Huque wrote: > On Fri, Apr 10, 2020 at 12:51 PM Bob Harold wrote: > >> Having read through the draft, and twice through the emails, I think the >> draft has the right balance in using the parent and child NS RRsets >> properly. >> >> I think the "extra"

Re: [DNSOP] New draft on delegation revalidation

Remember that in ICANN contracted TLDs and in some ccTLDs, a registry can only contact registrants by going through the registrars. So they sent the notices via the registrar. There is nothing preventing that. Actually there is -- there's no mechanism to do so. Registries and registrars

Re: [DNSOP] New draft on delegation revalidation

> On 12 Apr 2020, at 03:57, John Levine wrote: > > In article > you > write: >> Sure. Brian was asking specifically asking about the TLD case, so my >> answer was in that context. For that space, I think one of the issues is: >> even if they were willing to verify all the delegations, it

Re: [DNSOP] New draft on delegation revalidation

On Fri, Apr 10, 2020 at 12:51 PM Bob Harold wrote: > Having read through the draft, and twice through the emails, I think the > draft has the right balance in using the parent and child NS RRsets > properly. > > I think the "extra" query for the child NS, sent once per parent TTL, is a > savings

Re: [DNSOP] New draft on delegation revalidation

On Mon, Apr 13, 2020 at 3:21 PM Puneet Sood wrote: > +1 to the dnsop WG adopting this document. > > I have not read the document fully yet but will be commenting on it. Thank you Puneet - we look forward to your comments! ___ DNSOP mailing list

Re: [DNSOP] New draft on delegation revalidation

On Mon, Apr 13, 2020 at 4:36 PM Ólafur Guðmundsson wrote: > > I read the draft and like it, this is a clear statement of the problem and > good way forward. > Thanks Olafur! > I agree with the idea that "all" NS are lame is a good signal to > revalidate, > Yeah, me too. But as Paul later

Re: [DNSOP] New draft on delegation revalidation

I read the draft and like it, this is a clear statement of the problem and good way forward. I agree with the idea that "all" NS are lame is a good signal to revalidate, One idea to throw out here triggered by the first two paragraphs in section 3 Should we recommend that Authoritative servers

Re: [DNSOP] New draft on delegation revalidation

On Saturday, 11 April 2020 17:02:07 UTC Shumon Huque wrote: > On Sat, Apr 11, 2020 at 12:33 PM Stephane Bortzmeyer > wrote: > > ... > > > > I don't think that you answer Brian's idea. The way I've read his > > idea, he suggested, when a resolver detects a lame server (or when all > > servers are

Re: [DNSOP] New draft on delegation revalidation

On Saturday, 11 April 2020 13:22:42 UTC Shumon Huque wrote: > ... > > This might also be viewed (correctly) as a corner case in the RRR model > > > that doesn't get addressed; it seems to happen most frequently if a > > registrant changes registrars or if a domain lapses, where the previous > >

Re: [DNSOP] New draft on delegation revalidation

In article you write: >Sure. Brian was asking specifically asking about the TLD case, so my >answer was in that context. For that space, I think one of the issues is: >even if they were willing to verify all the delegations, it isn't clear what >they are permitted to do about it, beyond

Re: [DNSOP] New draft on delegation revalidation

On Sat, Apr 11, 2020 at 12:38 PM Stephane Bortzmeyer wrote: > On Sat, Apr 11, 2020 at 09:22:42AM -0400, > Shumon Huque wrote > a message of 138 lines which said: > > > I've heard proposals in the past that TLDs should routinely scan all > > their delegations to identify such problems, but I

Re: [DNSOP] New draft on delegation revalidation

On Sat, Apr 11, 2020 at 12:33 PM Stephane Bortzmeyer wrote: > On Sat, Apr 11, 2020 at 09:22:42AM -0400, > Shumon Huque wrote > a message of 138 lines which said: > > > > The delegation (re)validation might be a reasonable place to > > > implement something to detect this and adjust the choice

Re: [DNSOP] New draft on delegation revalidation

On Sat, Apr 11, 2020 at 09:22:42AM -0400, Shumon Huque wrote a message of 138 lines which said: > I've heard proposals in the past that TLDs should routinely scan all > their delegations to identify such problems, but I gather this is a > challenging requirement to impose on them for various

Re: [DNSOP] New draft on delegation revalidation

On Sat, Apr 11, 2020 at 09:22:42AM -0400, Shumon Huque wrote a message of 138 lines which said: > > The delegation (re)validation might be a reasonable place to > > implement something to detect this and adjust the choice of NS on > > the resolver's cache. > > I think most resolvers do a bit

Re: [DNSOP] New draft on delegation revalidation

On Sat, Apr 11, 2020 at 3:12 AM Brian Dickson wrote: > On Fri, Apr 10, 2020 at 6:46 AM Shumon Huque wrote: > >> Hi folks, >> >> Paul Vixie, Ralph Dolmans, and I have submitted this I-D for >> consideration: >> >>https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 >> >>

Re: [DNSOP] New draft on delegation revalidation

On Fri, Apr 10, 2020 at 6:46 AM Shumon Huque wrote: > Hi folks, > > Paul Vixie, Ralph Dolmans, and I have submitted this I-D for > consideration: > >https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 > > > Comments/discussion welcome. > There is one issue not addressed (here

Re: [DNSOP] New draft on delegation revalidation

Having read through the draft, and twice through the emails, I think the draft has the right balance in using the parent and child NS RRsets properly. I think the "extra" query for the child NS, sent once per parent TTL, is a savings over the older method of sending the NS records as "additional

Re: [DNSOP] New draft on delegation revalidation

(as a chair) I enjoyed reading the thread on dns-operations, and as a chair, both Benno and we like where this is going. (consider this a gentle nudge working group this is relevant to our interests) thanks Shumon/Ralph/Paul tim On Fri, Apr 10, 2020 at 9:46 AM Shumon Huque wrote: > Hi

[DNSOP] New draft on delegation revalidation

Hi folks, Paul Vixie, Ralph Dolmans, and I have submitted this I-D for consideration: https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 I mentioned it on the dns-operati...@dns-oarc.net mailing list last week, where the topic came up in another thread, and there has already