Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Puneet Sood]

Also the following section (2.2.1 - Special Handling of No Data)
suggests sending type 2 instead of type 1 responses but is silent
about type 3 responses.

On Fri, Apr 14, 2023 at 8:46 PM Puneet Sood  wrote:
>
> On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews  wrote:
> >
> > RFC 2038 already says add the SOA so negative answers can be cached. The 
> > other responses
> > where to show what was out there so that they where not misinterpreted.
> I believe you are referring to this sentence? Quote: "The authority
> section will contain an SOA record, or there will be no NS records
> there."
>
> That is not how I interpreted those lines. My understanding of the
> part after the "or" is that a response with an empty ANSWER and AUTH
> section also indicates NODATA (as confirmed by response type 3).
>
> > I doubt saying
> > don’t do those old forms will make any difference.  Everything out there 
> > has had 25 years
> > to comply.
> I understand updating the specs by itself does not fix compliance.
> However clarifying that "or" would be useful.
>
> >
> > > On 15 Apr 2023, at 09:06, Puneet Sood 
> > >  wrote:
> > >
> > > On the topic of authoritative server behavior as seen in the DNS
> > > responses, a few areas for improvement below (not touching DNSSEC).
> > > This is written from the perspective of a resolver using the auth
> > > responses to answer user queries.
> > >
> > > * responding correctly to requests with certain flags, EDNS options.
> > > This is covered well by RFC 8906. Now we wait for compliance.
> > >
> > > * proper glue
> > > This I-D clarifies the need to supply *all the glue* and to set TC=1
> > > correctly. Improve the specification for what to do with sibling or
> > > cyclic glue. Ideally recommend against publishing and/or depending on
> > > cyclic, sibling glue.
> > >
> > > * NODATA responses
> > > RFC 2308 section 2.2 - No Data
> > > [https://www.rfc-editor.org/rfc/rfc2308#section-2.2] describes three
> > > different ways an NS response could indicate NODATA. Types 1 and 2
> > > include a SOA record which is helpful in determining TTLs and start of
> > > the zone cut (this matters when the same auth server is authoritative
> > > for consecutive labels in a qname). Type 3 with no SOA while usable by
> > > resolvers is not very helpful.
> > >
> > > Tightening of the specification to require type 1 or 2 responses for
> > > NODATA will be beneficial (drop type 3).
> > >
> > > In addition two additional types of responses appear to show up in the
> > > wild. Tightening the spec likely won't help here.
> > > Type 4. SOA in Answer section
> > > Non-compliant but a resolver can kind of figure this out and use it to
> > > generate a NODATA answer.
> > >
> > > Implementation note: Viktor has done work on this topic so we should
> > > have some data to share in a few weeks.
> > >
> > > Type 5. NS RRs for the zone in question (no SOA) (type 1 w/o the SOA :()
> > > Generally treated as LAME.
> > >
> > > Questions for the working group:
> > > Is there interest in updating existing specifications around glue and
> > > NODATA responses?
> > >
> > > Are there other related auth response specifications which would
> > > benefit from updates?
> > >
> > > Thanks for reading.
> > >
> > > -Puneet
> > >
> > > On Tue, Mar 28, 2023 at 9:54 PM Shumon Huque  wrote:
> > >>
> > >> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  
> > >> wrote:
> > >>>
> > >>>
> > >>> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 3/28/23 03:14, Shumon Huque wrote:
> > >>>>> On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni 
> > >>>>> mailto:ietf-d...@dukhovni.org>> wrote:
> > >>>>>
> > >>>>>On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> > >>>>>Can we at least state that domains with cyclic dependencies are a 
> > >>>>> bad
> > >>>>>idea, and may not be supported by all resolvers.  In other words, 
> > >>>>> that
> > >>>>>the domain owner can't **rely** on the sibling glue recommended to 
> > >>>>> be
>

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Puneet Sood]

On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews  wrote:
>
> RFC 2038 already says add the SOA so negative answers can be cached. The 
> other responses
> where to show what was out there so that they where not misinterpreted.
I believe you are referring to this sentence? Quote: "The authority
section will contain an SOA record, or there will be no NS records
there."

That is not how I interpreted those lines. My understanding of the
part after the "or" is that a response with an empty ANSWER and AUTH
section also indicates NODATA (as confirmed by response type 3).

> I doubt saying
> don’t do those old forms will make any difference.  Everything out there has 
> had 25 years
> to comply.
I understand updating the specs by itself does not fix compliance.
However clarifying that "or" would be useful.

>
> > On 15 Apr 2023, at 09:06, Puneet Sood  
> > wrote:
> >
> > On the topic of authoritative server behavior as seen in the DNS
> > responses, a few areas for improvement below (not touching DNSSEC).
> > This is written from the perspective of a resolver using the auth
> > responses to answer user queries.
> >
> > * responding correctly to requests with certain flags, EDNS options.
> > This is covered well by RFC 8906. Now we wait for compliance.
> >
> > * proper glue
> > This I-D clarifies the need to supply *all the glue* and to set TC=1
> > correctly. Improve the specification for what to do with sibling or
> > cyclic glue. Ideally recommend against publishing and/or depending on
> > cyclic, sibling glue.
> >
> > * NODATA responses
> > RFC 2308 section 2.2 - No Data
> > [https://www.rfc-editor.org/rfc/rfc2308#section-2.2] describes three
> > different ways an NS response could indicate NODATA. Types 1 and 2
> > include a SOA record which is helpful in determining TTLs and start of
> > the zone cut (this matters when the same auth server is authoritative
> > for consecutive labels in a qname). Type 3 with no SOA while usable by
> > resolvers is not very helpful.
> >
> > Tightening of the specification to require type 1 or 2 responses for
> > NODATA will be beneficial (drop type 3).
> >
> > In addition two additional types of responses appear to show up in the
> > wild. Tightening the spec likely won't help here.
> > Type 4. SOA in Answer section
> > Non-compliant but a resolver can kind of figure this out and use it to
> > generate a NODATA answer.
> >
> > Implementation note: Viktor has done work on this topic so we should
> > have some data to share in a few weeks.
> >
> > Type 5. NS RRs for the zone in question (no SOA) (type 1 w/o the SOA :()
> > Generally treated as LAME.
> >
> > Questions for the working group:
> > Is there interest in updating existing specifications around glue and
> > NODATA responses?
> >
> > Are there other related auth response specifications which would
> > benefit from updates?
> >
> > Thanks for reading.
> >
> > -Puneet
> >
> > On Tue, Mar 28, 2023 at 9:54 PM Shumon Huque  wrote:
> >>
> >> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  
> >> wrote:
> >>>
> >>>
> >>> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 3/28/23 03:14, Shumon Huque wrote:
> >>>>> On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni  >>>>> <mailto:ietf-d...@dukhovni.org>> wrote:
> >>>>>
> >>>>>On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> >>>>>Can we at least state that domains with cyclic dependencies are a bad
> >>>>>idea, and may not be supported by all resolvers.  In other words, 
> >>>>> that
> >>>>>the domain owner can't **rely** on the sibling glue recommended to be
> >>>>>sent in this draft to save the day.
> >>>>>
> >>>>>My strong preference is still to delete all reference in the draft to
> >>>>>cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> >>>>>sibling glue primarily as a performance optimisation, and secondarily
> >>>>>as a last resort when the nameserver IP addresses are wrong or gone
> >>>>>from the authoritative zone (another bad practice).
> >>>>>
> >>>>>
> >>>>> Viktor - I've so far not seen many other people speak up in support of 
> >>>>&g

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Puneet Sood]

On the topic of authoritative server behavior as seen in the DNS
responses, a few areas for improvement below (not touching DNSSEC).
This is written from the perspective of a resolver using the auth
responses to answer user queries.

* responding correctly to requests with certain flags, EDNS options.
This is covered well by RFC 8906. Now we wait for compliance.

* proper glue
This I-D clarifies the need to supply *all the glue* and to set TC=1
correctly. Improve the specification for what to do with sibling or
cyclic glue. Ideally recommend against publishing and/or depending on
cyclic, sibling glue.

* NODATA responses
RFC 2308 section 2.2 - No Data
[https://www.rfc-editor.org/rfc/rfc2308#section-2.2] describes three
different ways an NS response could indicate NODATA. Types 1 and 2
include a SOA record which is helpful in determining TTLs and start of
the zone cut (this matters when the same auth server is authoritative
for consecutive labels in a qname). Type 3 with no SOA while usable by
resolvers is not very helpful.

Tightening of the specification to require type 1 or 2 responses for
NODATA will be beneficial (drop type 3).

In addition two additional types of responses appear to show up in the
wild. Tightening the spec likely won't help here.
Type 4. SOA in Answer section
Non-compliant but a resolver can kind of figure this out and use it to
generate a NODATA answer.

Implementation note: Viktor has done work on this topic so we should
have some data to share in a few weeks.

Type 5. NS RRs for the zone in question (no SOA) (type 1 w/o the SOA :()
Generally treated as LAME.

Questions for the working group:
Is there interest in updating existing specifications around glue and
NODATA responses?

Are there other related auth response specifications which would
benefit from updates?

Thanks for reading.

-Puneet

On Tue, Mar 28, 2023 at 9:54 PM Shumon Huque  wrote:
>
> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  wrote:
>>
>>
>> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
>>>
>>>
>>>
>>> On 3/28/23 03:14, Shumon Huque wrote:
>>> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni >> > > wrote:
>>> >
>>> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
>>> > Can we at least state that domains with cyclic dependencies are a bad
>>> > idea, and may not be supported by all resolvers.  In other words, that
>>> > the domain owner can't **rely** on the sibling glue recommended to be
>>> > sent in this draft to save the day.
>>> >
>>> > My strong preference is still to delete all reference in the draft to
>>> > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
>>> > sibling glue primarily as a performance optimisation, and secondarily
>>> > as a last resort when the nameserver IP addresses are wrong or gone
>>> > from the authoritative zone (another bad practice).
>>> >
>>> >
>>> > Viktor - I've so far not seen many other people speak up in support of 
>>> > your
>>> > position. I suspect this is because this draft was discussed to death many
>>> > months ago during long discussion threads on the list, and there is likely
>>> > already rough consensus for the current content. Personally, I would be ok
>>> > with adding a statement that configurations involving cyclic dependencies
>>> > are not recommended, but others will likely have to also speak up in 
>>> > support
>>> > of this too.
>>>
>>> I support adding such a statement about cyclic dependencies.
>>
>>
>> As do I.
>>
>>
>>>
>>>
>>> In addition, I would support saying that data suggests that, while 
>>> (non-cyclic) glue records may have a benefit in certain cases, they 
>>> frequently are a source of harm (time-outs), and the trade-off remains 
>>> unclear.
>>
>>
>> I would support this as well.
>>
>> In my anecdotal experience as an operator, I routinely encounter mismatches 
>> in sibling glue and child zone NS sets that appear to be due to the glue 
>> being forgotten.  My assumption is that, because it's not necessary to 
>> operate, when operators fail to update it they don't receive any kind of 
>> signal that something is wrong.
>>
>> Viktor's numbers are pretty clear data, though, so nobody should need my 
>> anecdotes to be convinced.  While sibling glue may be a useful optimisation 
>> in some cases, given how poorly maintained it is it seems to cause more 
>> problems than it solves.
>>
>
> I'd like to remind folks that the scope of this draft when it was adopted by 
> the working group was very narrow. Mainly to say that 'required' glue must 
> set TC=1 if it doesn't fit into the DNS response payload. That required 
> talking about other types of non-mandatory glue like sibling, but has not 
> proposed to change authoritative server behavior in those areas.
>
> If folks want to deprecate sibling glue entirely, it would be best to write 
> another draft saying that and see if we can get consensus on that.
>
> Shumon.
>
> 

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Puneet Sood]

I wanted to respond to this thread earlier, so apologies in advance
for late posting and if this is a no-op at this point. Me getting
confused about the last call for this draft
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/)
and https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/
being combined didn't help either.

The draft does not contain any reference to the rfc8499bis I-D or to
RFC 8499. It would be helpful to have a reference.

On Tue, Mar 28, 2023 at 9:54 PM Shumon Huque  wrote:
>
> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  wrote:
>>
>>
>> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
>>>
>>>
>>>
>>> On 3/28/23 03:14, Shumon Huque wrote:
>>> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni >> > > wrote:
>>> >
>>> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
>>> > Can we at least state that domains with cyclic dependencies are a bad
>>> > idea, and may not be supported by all resolvers.  In other words, that
>>> > the domain owner can't **rely** on the sibling glue recommended to be
>>> > sent in this draft to save the day.
>>> >
>>> > My strong preference is still to delete all reference in the draft to
>>> > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
>>> > sibling glue primarily as a performance optimisation, and secondarily
>>> > as a last resort when the nameserver IP addresses are wrong or gone
>>> > from the authoritative zone (another bad practice).
>>> >
>>> >
>>> > Viktor - I've so far not seen many other people speak up in support of 
>>> > your
>>> > position. I suspect this is because this draft was discussed to death many
>>> > months ago during long discussion threads on the list, and there is likely
>>> > already rough consensus for the current content. Personally, I would be ok
>>> > with adding a statement that configurations involving cyclic dependencies
>>> > are not recommended, but others will likely have to also speak up in 
>>> > support
>>> > of this too.
>>>
>>> I support adding such a statement about cyclic dependencies.
>>
>>
>> As do I.
>>
>>
>>>
>>>
>>> In addition, I would support saying that data suggests that, while 
>>> (non-cyclic) glue records may have a benefit in certain cases, they 
>>> frequently are a source of harm (time-outs), and the trade-off remains 
>>> unclear.
>>
>>
>> I would support this as well.
>>
>> In my anecdotal experience as an operator, I routinely encounter mismatches 
>> in sibling glue and child zone NS sets that appear to be due to the glue 
>> being forgotten.  My assumption is that, because it's not necessary to 
>> operate, when operators fail to update it they don't receive any kind of 
>> signal that something is wrong.
>>
>> Viktor's numbers are pretty clear data, though, so nobody should need my 
>> anecdotes to be convinced.  While sibling glue may be a useful optimisation 
>> in some cases, given how poorly maintained it is it seems to cause more 
>> problems than it solves.

If it's not too late in the process:
Given the numbers presented upthread, at a minimum could we have one
sentence in section 2.3 Glue Cyclic Sibling Domain Name Server,
discouraging implementers from doing this?

>>
>
> I'd like to remind folks that the scope of this draft when it was adopted by 
> the working group was very narrow. Mainly to say that 'required' glue must 
> set TC=1 if it doesn't fit into the DNS response payload. That required 
> talking about other types of non-mandatory glue like sibling, but has not 
> proposed to change authoritative server behavior in those areas.
>
> If folks want to deprecate sibling glue entirely, it would be best to write 
> another draft saying that and see if we can get consensus on that.

This is a reasonable position. Sending a separate email.

-Puneet

>
> Shumon.
>
> ___
> 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-hardaker-dnsop-nsec3-guidance

[Puneet Sood]

I support adoption of this document to provide guidance for operators to
pick sensible NSEC3 parameters and for expected resolver behavior.

-Puneet


On Mon, May 10, 2021 at 4:56 AM Benno Overeinder  wrote:

> Hi all,
>
> As a follow-up to the presentation by Wes Hardaker at the IETF 110 DNSOP
> meeting, we want to start a call for adoption of
> draft-hardaker-dnsop-nsec3-guidance on the mailing list.
>
> With the presentation at the DNSOP meeting on IETF 110, there was a
> sufficient general support in the (virtual) room to adopt the draft as a
> working group document.
>
> Now we will start a period of two weeks for the call for adoption of
> draft-hardaker-dnsop-nsec3-guidance on the mailing list.
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/.
>
> 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.
>
> This call for adoption ends: 24 May 2021
>
>
> Thanks,
>
> -- Benno
>
> 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] draft-ietf-dnsop-extended-error status

[Puneet Sood]

On Wed, Oct 2, 2019 at 2:43 AM Vladimír Čunát
 wrote:
>
> On 9/30/19 11:47 PM, Warren Kumari wrote:
> > On Mon, Sep 30, 2019 at 7:54 AM Tony Finch  wrote:
> >> Difficult. In general there will be multiple upstream servers, even in
> >> the simplest case of a stub talking to a recursive server talking directly
> >> to authoritative servers. So there can be an arbitrary combination of
> >> upstream errors, and they might not relate directly to the QNAME, (e.g.
> >> problems with a parent zone, problems chasing down nameserver addresses).
> > RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) speaketh thusly:
> >
> > "EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is
> > negotiated between each pair of hosts in a DNS resolution process,
> > for instance, the stub resolver communicating with the recursive
> > resolver or the recursive resolver communicating with an
> > authoritative server."
> >
> > and also sayeth:
> > "OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from
> > master files."
> >
> > I *think* that this covers the issue for many cases; EDE is not
> > intended to be a silver bullet, more something which provides useful
> > information for troubleshooting / debugging.
> > We would not (and cannot :-)) preclude other work from further
> > defining this, but I think that it's beyond the scope of this document
> > / we will better be able to understand things once we've had some
> > deployment experience.
>
> My understanding is that the hop-by-hop condition is just the default
> and as suggested we could define/allow e.g. that if all upstreams return
> "filtered", we send the same downstream.  I expect we could first
> publish RFC without propagation of these errors in mind, but there's a
> risk that when we later want to add that, we'll need to make too big
> changes, e.g. we may miss something like the near/far flag mentioned
> earlier.
>
> If we/you don't want to deal with the propagation now, reserving some
> bits for future use (MUST zero now) might be a nice compromise, assuming
> we at least have some vague idea that a few of them are likely to be
> useful in future.  Another plan might be to do nothing now and later we
> might: (1) define another EDNS0 extension that will *separately* carry
> information in addition to this EDE or (2) define new flags within the
> current EDE and utilize the allowance of sending multiple EDEs.  These
> options sound a bit messier to me, but they seem doable.

To me the authors' consensus seems to be towards getting EDE into the
real world and learning from its experience to improve it/build
something better. That sounds like EXPERIMENTAL to me. That way
leaving the caching/forwarding behavior unspecified is fine. Based on
experience in the real world, we come back and define/implement EDEv2
and deprecate EDEv1.

Too naive?

For Google Public DNS, EDE or something like it which makes it easier
for users to self-diagnose problems with our responses would be a
great thing.

-Puneet

>
> --Vladimir
>
> ___
> 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] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Puneet Sood]

On Tue, Oct 22, 2019 at 6:49 AM Tony Finch  wrote:
>
> Petr Špaček  wrote:
> >
> > 2. Second problem is that it is uncelar if there is going to be a
> > consumer: Did *anyone* from stub resolvers said a word about this draft?
> > Is it useful as it is?
>
> I expect almost no-one can do anything with EDE without
> getaddrinfo() EAI_ return code extensions.

At a minimum dig should be able to support it. Does any of the dig
variants have support for EDE yet?

>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Plymouth: Variable 4 or less. Smooth or slight, occasionally moderate later in
> west. Mainly fair. Good.___
> 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] AD review of draft-ietf-dnsop-serve-stale-07

[Puneet Sood]

On Sat, Sep 14, 2019 at 8:46 AM Barry Leiba  wrote:
>
> > > I wonder if it makes sense to be more explicit here that one isn’t
> > > meant to keep using expired data forever, but is expected to keep
> > > trying to refresh it.  So, maybe?:
> > >
> > > NEW
> > >   If the data is unable to be
> > >   authoritatively refreshed when the TTL expires, the record MAY be
> > >   used as though it is unexpired until an authoritative refresh is
> > >   successful.
> > > END
> >
> > I think your proposed text is worse since it contradicts the current
> > draft, which limits the time during which you can serve stale answers
> > "The maximum stale timer should be configurable, and defines the
> > length of time after a record expires that it should be retained in
> > the cache.  The suggested value is between 1 and 3 days. [Even if you
> > cannot contact the authoritative servers, my note.]"
>
> Yes, true.  So maybe add "for a period of time or" before "until" in
> my suggestion.  Or see if you can come up with better wording.  If you
> really think it doesn't need to be qualified here because the rest of
> the document takes care of it, I won't push it further.  I just think
> it best to say *something* here that doesn't make it sound like an
> entirely open-ended "MAY".

I would prefer to not make the text in this paragraph too long since
other sections go into detail on the conditions when the stale data
can still be used. How about the following?

"If the data is unable to be authoritatively refreshed when the TTL expires,
the record MAY be used as though it is unexpired as long as certain
conditions are met. See the Example Method and Implementation
Considerations sections for details."

>
> > > Is another possible new security consideration that bad actors could
> > > DDoS authoritative servers with the explicit intent of having stale
> > > cached information used for longer, perhaps to extend the life of a
> > > cache-poisoning attack or some such?
> >
> > Yes, seems right. Also reported by Viktor Dukhovni during the last
> > call. May be add at the end of section 10 "Attackers could be incited
> > to dDoS authoritative servers with the explicit intent of having stale
> > cached information used for longer. But if they have this capacity,
> > they probably could do much worse things than prolongating old data."
>
> Other than that "prolongating" isn't a word (use "prolonging the life
> of"), that's probably OK.  Maybe add that the benefit outweighs the
> risk, or some such, and then we'll see what the Sec ADs think.

Added wording in the second paragraph of the Security Considerations section.

-Puneet

>
> Barry
>
>
> Barry

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

Re: [DNSOP] AD review of draft-ietf-dnsop-serve-stale-07

[Puneet Sood]

Barry,

Thanks for the detailed review. The editorial comments and security
considerations comment will be addressed in a new draft I will be
pushing.

On Wed, Sep 11, 2019 at 12:06 PM Barry Leiba  wrote:
>
> I am handling this document as responsible AD, as Warren is a
> co-author and so must recuse himself.  I’m not sure how I missed the
> publication request, but miss it I did, and thanks to Warren for
> pinging me.
>
> Thanks for a very well-written and clear document.  I have only some
> minor editorial comments and a couple of questions, all of which can
> be addressed along with any last-call comments that come along.  I’ll
> request last call right after I send this message.
>
> — Abstract —
>
>data can be kept in the cache beyond the TTL expiry, and also updates
>RFC 2181 by interpreting values with the high order bit set as being
>positive, rather than 0, and also suggests a cap of 7 days.
>
> The chain of “and also”s feels awkward; I would remove the first one,
> so “…TTL expiry, updates RFC 2181…”.  (I might remove the second
> “also” as well, as “and suggests” is fine without it.)  This text is
> also in the Introduction, so whatever change is made in the Abstract
> should be made in the Introduction too.
DONE

>
> — Introduction —
>
>This document proposes that the definition of the TTL be explicitly
>expanded to allow for expired data to be used in the exceptional
>
> This isn’t wrong, but for a standards-track document we would usually
> say, “This document expands the definition of the TTL to explicitly
> allow for…”.  It will be published as a Proposed Standard, so I guess
> the “proposed” part can just come from there, yes?
DONE

>
> — Section 3 —
>
>This is again not [RFC2119]-normative
>language, but does convey the natural language connotation that data
>
> In my ongoing effort to disabuse people of the idea that language has
> to have BCP 14 key words in order to be normative, I would prefer that
> this say, “This wording again does not contain BCP 14 key words,
> but…,” because I do believe the quoted text is normative.
DONE

>
>Several recursive resolver operators currently use stale data for
>answers in some way, including Akamai.
>
> Misplaced modifier:
> NEW
>Several recursive resolver operators, including Akamai, currently
>use stale data for answers in some way.
> END
DONE

>
>collective operational experience is that it provides significant
>benefit with minimal downside.
>
> The antecedent to “it” is unclear (it could refer to Apple MacOS or
> the Happy Eyeballs algorithm or mDNSResponder).  Better to say, “…is
> that using stale data can provide….”
DONE

>
> — Section 4 —
>
>   If the data is unable to be
>   authoritatively refreshed when the TTL expires, the record MAY be
>   used as though it is unexpired.
>
> I wonder if it makes sense to be more explicit here that one isn’t
> meant to keep using expired data forever, but is expected to keep
> trying to refresh it.  So, maybe?:
>
> NEW
>   If the data is unable to be
>   authoritatively refreshed when the TTL expires, the record MAY be
>   used as though it is unexpired until an authoritative refresh is
>   successful.
> END

Addressing along with Stephane's response.

>
> — Section 5 —
>
> “implementation dependent” needs a hyphen: “implementation-dependent”
DONE

>
> — Section 6 —
>
>fact that no other RCODEs which a resolver normally encounters makes
>any assertions regarding the name in the question
>
> Number agreement: “make any assertions”  (I would also change “which”
> to “that”, but I’m picky about using “that” to introduce restrictive
> clauses.)
DONE

>
>existing cache state.  Some authoritative servers operators have said
>
> Either “authoritative server operators” or “authoritative servers’
> operators”; I think the former.
DONE

>
>their servers are responding with errors like ServFail instead of
>giving true authoritative answers.  Implementers MAY decide to return
>stale answers in this situation.
>
> It might be good for the last paragraph in Section 4, with the
> “SHOULD”, to have a forward reference to this explanation.
DONE

>
> — Section 10 —
>
> Is another possible new security consideration that bad actors could
> DDoS authoritative servers with the explicit intent of having stale
> cached information used for longer, perhaps to extend the life of a
> cache-poisoning attack or some such?

Added wording with suggested text from Stephane.

-Puneet

>
> --
> Barry

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

Re: [DNSOP] [dns-privacy] Do53 vs DoT vs DoH Page Load Performance Study at ANRW

[Puneet Sood]

Thanks for sharing the results of your work. It will be great to have
the software available so others can run the experiments from other
locations.

When looking at the page load results the CDF graphs comparing the
various services are very useful to see the relative performance of
different services. However I could not find the range of time values
for the page loads in the experiment. Basically what percentage of the
page load time variation was related to DNS?

Note: For Google DoH, we will be reviewing our implementation for
latency. BTW we have launched our production RFC 8484 DoH service
recently at https://dns.google/dns-query
(https://security.googleblog.com/2019/06/google-public-dns-over-https-doh.html).
It will be great if you can update your software to use this endpoint.

* The experiment was run from Princeton, New Jersey in Northeast US.
The location is in a very well connected part of the world between
network peering points in NYC and Washington DC. You will not see much
difference (due to network latency) between the cloud providers and
the default (local) Do53. Running the experiment from locations which
are further away from cloud providers would provide another
interesting set of data.

* Conclusion on benefit (or lack) of ECS.
Did the page load measurements include content that would benefit from
proximity to the end user, e.g. streaming videos or large downloads?
This kind of content benefits from ECS when the resolver is further
away from the client.

Thanks,
Puneet

On Fri, Jul 19, 2019 at 1:42 AM Kevin Borgolte  wrote:
>
>
> > This paper looks interesting. Is the software used in the paper published?
>
> Thanks! The code isn’t open source yet, but we will make it public alongside 
> the Docker setup we used for running it. Not sure when that is going to 
> happen exactly though.
>
> > Or, at least, is the test page set published? I haven't read the whole 
> > thing yet, but it seems like the page set would be relevant if the paper 
> > tests page load time.
>
> The list of websites is attached. It is extracted from the top 1,000 and 
> 99,000 to 100,000 of a Tranco list.
>
> Best,
> Kevin
>
> ___
> dns-privacy mailing list
> dns-priv...@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

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

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Puneet Sood]

Reposting to the list what I shared with Richard Bennett earlier.

The Google Public DNS privacy policy is at
https://developers.google.com/speed/public-dns/privacy. Maybe I should
have included a link to it in the earlier email. If you have comments
on it, please share.

We are following https://tools.ietf.org/html/draft-ietf-dprive-bcp-op
and have commented on an earlier version.

-Puneet

On Sat, Mar 23, 2019 at 3:48 AM Richard Bennett  wrote:
>
> I like it if you would kindly define “privacy” in the context of “a DNS 
> resolver that protects our users’ privacy.” Does that mean hiding their 
> lookups from ISPs who might want to enter the market for targeted ads while 
> using them for your company’s own purposes, or just protecting user queries 
> made over insecure public Wi-Fi networks from easy snooping? Because there 
> are better ways to do the latter than with a system that opts users into a 
> centralized resolver.
>
> RB
>
> On Mar 22, 2019, at 4:08 PM, Puneet Sood 
>  wrote:
>
> Hello,
>
> There has been much discussion in the IETF lists over the impact of
> using DNS-over-HTTPS (DoH) in a network. We would like to clarify the
> Google Public DNS position on this topic. The post I am replying to is
> particularly relevant since it makes some assumptions about the plans
> of the Google Public DNS service.
>
> For future support of a RFC 8484 compliant service, we plan to do the 
> following:
> * Serve RFC 8484 compliant DoH from the well known Google Public DNS
> anycast IP addresses (e.g. 8.8.8.8) on the standard HTTPS port 443.
> * Migrate our existing DoH services to the well known Google Public
> DNS anycast IP addresses, including the beta version (at
> https://dns.google.com/resolve) and IETF draft version (at
> https://dns.google.com/experimental).
>
> The Google Public DNS anycast IP addresses are distinct from the IP
> addresses used to host web content for Google properties. This will
> allow operators to control access to the Google Public DNS DoH service
> on their networks without impeding access to other Google services.
>
> For DoH implementers we want to ensure the same access to our
> implementation whether it is a Google product (like the Chrome
> browser) or a third-party product. To this end we aim to track IETF
> work on standardized ways to detect DoH support by the system-selected
> DNS resolver service (like
> https://tools.ietf.org/html/draft-ietf-doh-resolver-associated-doh-02
> or https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-01).
>
> As a core principle, Google Public DNS aims to provide a DNS resolver
> that respects our users’ privacy. Towards that goal, we aim to provide
> high quality implementations of various DNS transport mechanisms that
> our users can use to reach the service. This includes the traditional
> UDP and TCP transports as well as DNS-over-TLS and DNS-over-HTTPS that
> provide privacy for the user’s communication with a DNS resolver.
>
> -Puneet Sood
> TL/Manager for the Google Public DNS team.
>
> PS: I am attending IETF 104 and will be available for face-to-face discussion.
>
> On Wed, Mar 20, 2019 at 2:40 PM 神明達哉  wrote:
>
>
> At Wed, 20 Mar 2019 12:38:05 +0100,
> Joe Abley  wrote:
>
> Often as an industry we may discuss various solutions that are great for 
> oneself but don’t scale when looking at the big picture.
>
>
> I think what we are seeing is the fundamental tension between privacy and 
> control. You need to give up some privacy in order to make the control 
> possible; you need to give up some control in order to afford privacy.
>
>
> Some in this thread want certainty that they are able to exercise control, 
> e.g. for devices in their network.
>
>
> Some in this thread want certainty that they can obtain privacy, e.g. for for 
> their device in any network.
>
>
> [...]
>
> Thank you for the nice, concise summary.  I think it's well-balanced
> observation of where we are.  (I'm so glad I can finally see a
> constructive post after seeing a common pattern of boring IETF
> discussion, where people with different opinions just keep stating
> their views without making any real progress:).
>
> Seems to me that there's a middle ground within sight here.
>
> Standardise this privacy mechanism, and specify (with reasoning) that it 
> should be implemented such that the existence of the channel (but not the 
> content) can be identified as distinct from other traffic by third parties. 
> Maybe specify use of a different port number, as was done with DoT.
>
>
> I see that those who want to exercise control can live with this (or
> at least using a different set of IP addresses for DoH servers than
> those for other ordinary web s

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Puneet Sood]

Hello,

There has been much discussion in the IETF lists over the impact of
using DNS-over-HTTPS (DoH) in a network. We would like to clarify the
Google Public DNS position on this topic. The post I am replying to is
particularly relevant since it makes some assumptions about the plans
of the Google Public DNS service.

For future support of a RFC 8484 compliant service, we plan to do the following:
* Serve RFC 8484 compliant DoH from the well known Google Public DNS
anycast IP addresses (e.g. 8.8.8.8) on the standard HTTPS port 443.
* Migrate our existing DoH services to the well known Google Public
DNS anycast IP addresses, including the beta version (at
https://dns.google.com/resolve) and IETF draft version (at
https://dns.google.com/experimental).

The Google Public DNS anycast IP addresses are distinct from the IP
addresses used to host web content for Google properties. This will
allow operators to control access to the Google Public DNS DoH service
on their networks without impeding access to other Google services.

For DoH implementers we want to ensure the same access to our
implementation whether it is a Google product (like the Chrome
browser) or a third-party product. To this end we aim to track IETF
work on standardized ways to detect DoH support by the system-selected
DNS resolver service (like
https://tools.ietf.org/html/draft-ietf-doh-resolver-associated-doh-02
or https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-01).

As a core principle, Google Public DNS aims to provide a DNS resolver
that respects our users’ privacy. Towards that goal, we aim to provide
high quality implementations of various DNS transport mechanisms that
our users can use to reach the service. This includes the traditional
UDP and TCP transports as well as DNS-over-TLS and DNS-over-HTTPS that
provide privacy for the user’s communication with a DNS resolver.

-Puneet Sood
TL/Manager for the Google Public DNS team.

PS: I am attending IETF 104 and will be available for face-to-face discussion.

On Wed, Mar 20, 2019 at 2:40 PM 神明達哉  wrote:
>
> At Wed, 20 Mar 2019 12:38:05 +0100,
> Joe Abley  wrote:
>
> > > Often as an industry we may discuss various solutions that are great for 
> > > oneself but don’t scale when looking at the big picture.
> >
> > I think what we are seeing is the fundamental tension between privacy and 
> > control. You need to give up some privacy in order to make the control 
> > possible; you need to give up some control in order to afford privacy.
>
> > Some in this thread want certainty that they are able to exercise control, 
> > e.g. for devices in their network.
>
> > Some in this thread want certainty that they can obtain privacy, e.g. for 
> > for their device in any network.
>
> [...]
>
> Thank you for the nice, concise summary.  I think it's well-balanced
> observation of where we are.  (I'm so glad I can finally see a
> constructive post after seeing a common pattern of boring IETF
> discussion, where people with different opinions just keep stating
> their views without making any real progress:).
>
> > Seems to me that there's a middle ground within sight here.
> >
> > Standardise this privacy mechanism, and specify (with reasoning) that it 
> > should be implemented such that the existence of the channel (but not the 
> > content) can be identified as distinct from other traffic by third parties. 
> > Maybe specify use of a different port number, as was done with DoT.
>
> I see that those who want to exercise control can live with this (or
> at least using a different set of IP addresses for DoH servers than
> those for other ordinary web services).  But I'm not so sure if that's
> acceptable for the other group..  In that sense I'm curious whether
> some big possible DoH providers are now willing to accept this middle
> ground.  If my memory is correct the longer term plan at Google (and
> maybe also Clouldflare?) is to provide DoH service on the same IP
> addresses as those for other ordinary and popular web services (and on
> port 443, of course), so that an intermediate operator cannot easily
> block access to their DoH services.
>
> > Those who choose to ignore that direction and create a covert channel using 
> > port 443 instead will do so. Nothing much we can do to stop that today (I 
> > guarantee it is already happening). The future is not really different.
>
> True.  But I think giant providers tend to respect a community
> consensus.  Niche or really malicious players may/will still ignore
> it, but it would be very difficult for them to collocate their DoH
> services with other important web services that can hardly be blocked,
> so it shouldn't be a big problem for "those who want certainty of
> control".  So if we can re