Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated

[Peter van Dijk]

Hi Benno,

On Thu, 2021-07-29 at 23:48 +0200, Benno Overeinder wrote:
> As a follow up to Shumon's email, the order is indeed different than 
> usual.  Normally we schedule current business first, but for 
> agenda-technical reasons (allowing discussion) we have changed the order.
> 
> Hope you understand the exception to the rule.

Right, that argument works both ways, of course.

Option 1: schedule the draft at the end and promise to get to it 10
minutes before the end - in other words, hope that you can manage to
cut the priority discussion short.

Option 2 (chosen here): get the draft out of the way first and hope
that we manage to limit discussion time on it, to leave time for the
wider WG discussion on priorities.

It is understood. Thank you.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated

[Peter van Dijk]

Hello Shumon,

On Thu, 2021-07-29 at 14:49 -0400, Shumon Huque wrote:
> 
> I'm sure the chairs will answer you on process, but I wanted to state that I
> had actually posted -00 before the draft cutoff (-01 posted later was a minor
> tweak) and asked for agenda time then. The chairs apologized to me later 
> that they hadn't responded earlier and said they could fit me on Thursday.

Ah, apologies, then - I assumed it was post-cutoff because I did not notice any 
email about the draft on dnsop pre-cutoff.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated

[Benno Overeinder]

As a follow up to Shumon's email, the order is indeed different than 
usual.  Normally we schedule current business first, but for 
agenda-technical reasons (allowing discussion) we have changed the order.


Hope you understand the exception to the rule.

Best,

-- Benno


On 29/07/2021 21:04, Shumon Huque wrote:
On Thu, Jul 29, 2021 at 2:49 PM Shumon Huque > wrote:


On Thu, Jul 29, 2021 at 2:41 PM Peter van Dijk
mailto:peter.van.d...@powerdns.com>>
wrote:


This is not a comment on the specific draft at all. This is a
comment
on WG process. It seems weird to me to discuss prioritisation
-after-
we spend time talking about current and, especially, new business.


I'm sure the chairs will answer you on process, but I wanted to
state that I
had actually posted -00 before the draft cutoff (-01 posted later
was a minor
tweak) and asked for agenda time then. The chairs apologized to me
later
that they hadn't responded earlier and said they could fit me on
Thursday.


Quick followup - I'm happy to go at the end. I'm not even sure I was 
going to

ask for adoption - this was more information sharing, and asking the WG what
I should do with this draft. So it need not impact the current work 
prioritization
discussion. (I am assuming the WG will not bless the BL method, so it is 
unlikely

to adopt it or a derivative, but I may be surprised).

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] Empty Non-Terminal sentinel for Black Lies

[Shumon Huque]

On Thu, Jul 29, 2021 at 2:29 PM Peter van Dijk 
wrote:

> >
> >Empty Non-Terminal Sentinel for Black Lies
> >
> > Abstract
> >
> >The Black Lies method of providing compact DNSSEC denial of existence
> >proofs has some operational implications.  Depending on the specific
> >implementation, it may provide no way to reliably distinguish Empty
> >Non-Terminal names from names that actually do not exist.  This draft
> >describes the use of a synthetic DNS resource record type to act as
> >an explicit signal for Empty Non-Terminal names and which is conveyed
> >in an NSEC type bitmap.
>
> I have read the draft, and I believe I understand what the draft is doing.
> I have also read the Introduction and Motivation section. While it does
> contain some motivation, I do not think it contains enough motivation. One
> might argue that ENT/NXDOMAIN problems do not exist with these operators,
> precisely because they do Black Lies.
>
> Furthermore, it looks like a trick that could only be relied on with
> specific operators (such as, for now, NS1) that have implemented it. There
> are plenty of differences between the implementations already. In fact,
> when promoting RFC8482, CloudFlare heavily argued how the difference
> between NODATA and NXDOMAIN is a very expensive one for them. So
> presumably, it would not make sense for them to implement this signal.
> Because of that, I wonder if it would not make more sense if the individual
> implementers/operators of things that are somewhat similar under the 'Black
> Lies'-umbrella document how they signal the difference between ENT and
> NXDOMAIN. (It would of course be fine if some of them agree on the signal).
>

Hi Peter,

Yes, Cloudflare is a bit different than the other 2 implementations - they
did not exactly follow the spec as described in the expired ID (presumably
for the reason you mention, although I don't know enough about their
implementation to know why it's hard for them). For any NODATA, including
ENT they return a NSEC bitmap that contains every (~ 20) RR type they
support except for the queried type. I mention this in the draft. So, they
effectively avoid the NXDOMAIN/ENT distinguishability problem that way.

I also hope, but want to say that out loud here, that there is no expection
> of -resolver- software to handle this signal in any special way.
>

Confirmed! :)

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

Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated

[Shumon Huque]

On Thu, Jul 29, 2021 at 2:49 PM Shumon Huque  wrote:

> On Thu, Jul 29, 2021 at 2:41 PM Peter van Dijk <
> peter.van.d...@powerdns.com> wrote:
>
>>
>> This is not a comment on the specific draft at all. This is a comment
>> on WG process. It seems weird to me to discuss prioritisation -after-
>> we spend time talking about current and, especially, new business.
>>
>>
> I'm sure the chairs will answer you on process, but I wanted to state that
> I
> had actually posted -00 before the draft cutoff (-01 posted later was a
> minor
> tweak) and asked for agenda time then. The chairs apologized to me later
> that they hadn't responded earlier and said they could fit me on Thursday.
>

Quick followup - I'm happy to go at the end. I'm not even sure I was going
to
ask for adoption - this was more information sharing, and asking the WG what
I should do with this draft. So it need not impact the current work
prioritization
discussion. (I am assuming the WG will not bless the BL method, so it is
unlikely
to adopt it or a derivative, but I may be surprised).

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

Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated

[Joe Abley]

Hi Peter,

On 29 Jul 2021, at 14:39, Peter van Dijk  wrote:

> On this version, I see under New Working Group Business a draft (the
> black lies sentinel) that was posted two days ago. Can somebody please
> explain to me what the purpose of the draft cutoff is, if drafts can
> appear in the datatracker, and on an agenda, after the cutoff?

I believe it has long been the case that the IETF resumes accepting new 
documents at the start of IETF week. This allows people to document ideas that 
come up in corridors and in the bar during the actual event.

(Remember actual events? In the Before Times, we had them.)

The purpose of the cut-off as I understand it is that agendas and meeting slots 
are supposed to be organised long in advance of that, and that it's useful to 
suspend new documents to avoid the rug being pulled out from that 
administrative process.

The case where a document is submitted before the deadline and gets agenda time 
but is updated before the meeting is not unremarkable either, I think, although 
I think references to the new version would properly be made informally and 
obviously not in the slides that were definitely submitted well in advance.

I can't speak to the black lies draft, for which I understand new terminology 
is eagerly anticipated before anybody else mentions it, but that's my general 
idea of what is going on in the world.

I miss actual events.


Joe

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

Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated

[Shumon Huque]

On Thu, Jul 29, 2021 at 2:41 PM Peter van Dijk 
wrote:

> On Wed, 2021-07-28 at 17:04 +0200, Benno Overeinder wrote:
> > Dear WG,
> >
> > We have updated the agenda for DNSOP WG session II on Thursday 29 July.
> >   The updated agenda is uploaded to datatracker:
> > https://datatracker.ietf.org/meeting/111/materials/agenda-111-dnsop-06
>
> On this version, I see under New Working Group Business a draft (the
> black lies sentinel) that was posted two days ago. Can somebody please
> explain to me what the purpose of the draft cutoff is, if drafts can
> appear in the datatracker, and on an agenda, after the cutoff?
>
> In the latest version (
> https://datatracker.ietf.org/meeting/111/materials/agenda-111-dnsop-07)
> , I see the new business has now been moved -in front- of both current
> business, and the discussion on prioritisation of WG activities.
>
> This is not a comment on the specific draft at all. This is a comment
> on WG process. It seems weird to me to discuss prioritisation -after-
> we spend time talking about current and, especially, new business.
>
>
I'm sure the chairs will answer you on process, but I wanted to state that I
had actually posted -00 before the draft cutoff (-01 posted later was a
minor
tweak) and asked for agenda time then. The chairs apologized to me later
that they hadn't responded earlier and said they could fit me on Thursday.

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

Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated

[Peter van Dijk]

On Wed, 2021-07-28 at 17:04 +0200, Benno Overeinder wrote:
> Dear WG,
> 
> We have updated the agenda for DNSOP WG session II on Thursday 29 July. 
>   The updated agenda is uploaded to datatracker: 
> https://datatracker.ietf.org/meeting/111/materials/agenda-111-dnsop-06

On this version, I see under New Working Group Business a draft (the
black lies sentinel) that was posted two days ago. Can somebody please
explain to me what the purpose of the draft cutoff is, if drafts can
appear in the datatracker, and on an agenda, after the cutoff?

In the latest version (
https://datatracker.ietf.org/meeting/111/materials/agenda-111-dnsop-07)
, I see the new business has now been moved -in front- of both current
business, and the discussion on prioritisation of WG activities.

This is not a comment on the specific draft at all. This is a comment
on WG process. It seems weird to me to discuss prioritisation -after-
we spend time talking about current and, especially, new business.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies

[Peter van Dijk]

Hi Shumon,

On Tue, 2021-07-27 at 19:34 -0400, Shumon Huque wrote:
> Folks,
> 
> While we have the attention of DNSOP folks this week, I'd like to ask for 
> review of this draft (I meant to send it earlier in time for f2f discussion 
> on Tuesday, but better late than never).
> 
> https://datatracker.ietf.org/doc/html/draft-huque-dnsop-blacklies-ent-01
> 
> Excerpt:
> 
>Empty Non-Terminal Sentinel for Black Lies
> 
> Abstract
> 
>The Black Lies method of providing compact DNSSEC denial of existence
>proofs has some operational implications.  Depending on the specific
>implementation, it may provide no way to reliably distinguish Empty
>Non-Terminal names from names that actually do not exist.  This draft
>describes the use of a synthetic DNS resource record type to act as
>an explicit signal for Empty Non-Terminal names and which is conveyed
>in an NSEC type bitmap.

I have read the draft, and I believe I understand what the draft is doing. I 
have also read the Introduction and Motivation section. While it does contain 
some motivation, I do not think it contains enough motivation. One might argue 
that ENT/NXDOMAIN problems do not exist with these operators, precisely because 
they do Black Lies.

Furthermore, it looks like a trick that could only be relied on with specific 
operators (such as, for now, NS1) that have implemented it. There are plenty of 
differences between the implementations already. In fact, when promoting 
RFC8482, CloudFlare heavily argued how the difference between NODATA and 
NXDOMAIN is a very expensive one for them. So presumably, it would not make 
sense for them to implement this signal. Because of that, I wonder if it would 
not make more sense if the individual implementers/operators of things that are 
somewhat similar under the 'Black Lies'-umbrella document how they signal the 
difference between ENT and NXDOMAIN. (It would of course be fine if some of 
them agree on the signal).

I also hope, but want to say that out loud here, that there is no expection of 
-resolver- software to handle this signal in any special way.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

[John R Levine]

On Thu, 29 Jul 2021, Jared Mauch wrote:

I think calling out that it’s possible people will create situations where a 
name won’t resolve, is similar to what happens with routing that isn’t 
deterministic as well.  We should be defining how to determinsticly resolve a 
name and highlight that it’s flexible enough you can configure it so it won’t 
work.


Sounds reasonable.  I'd also like us to keep in mind what our capitalized 
words mean.  MUST means "do this to interoperate".  The only MUST I've 
seen in this document is that servers MUST return all in-bailiwick glue.


I don't think there's anything harmful about returning sibling glue, but 
it is 100% optional. Ignoring NS loops, anything you can get with sibling 
glue you can get by another query, which makes it a MAY.  Maybe two 
queries are slower, maybe the single response with extra glue needed a 
retry with TCP while the two simpler responses could each use UDP, so 
maybe not.


Conflating it with in-bailiwick glue is 100% confusing, which I why I 
think we should drop it and stick to the important point about all the 
in-bailiwick glue.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

[Jared Mauch]

On Thu, Jul 29, 2021 at 11:45:28AM +1000, Geoff Huston wrote:
> 
> 
> > On 29 Jul 2021, at 10:33 am, Mark Delany  wrote:
> > 
> > On 29Jul21, Geoff Huston allegedly wrote:
> > 
> >> For me it appears to depend on the actions of the resolver as to whether 
> >> this would be faster
> >> or not. If all resolvers blindly re-query using TCP for all UDP responses 
> >> where TC=1 is seen in
> > 
> > I'm not sure I follow this bit. Are you merely implying that the resolver 
> > should first
> > consider a larger edns0 bufsize before resorting to TCP?
> 
> Seems that the DNS Flag Day 2020 precluded that option, so I don’t think its 
> available.


I think we should simplify the number of ways we do something,
be it edns0 or tcp.  We are seeing the difference in everyone wanting
their own way/transport/whatnot and therefore keep growing the methods
to get the same data.

But yes, as we increase the default answer size with additional
glue, signatures, validation, we should be following and sizing as
appropriate.

- Jared

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

[Jared Mauch]

> On Jul 28, 2021, at 12:16 AM, John Levine  wrote:
> 
> OK, so I ask for foo.example and I get 
> 
> ; answer
> foo.example NS ns.bar.example
> ; additional
> ns.bar.example  2001:0DB8::000b::2
> 
> Does it check that's the right value for ns.bar.example?  How about with 
> DNSSEC?  I suppose
> 
> I still don't see the benefit of trying to make some loops work when we know 
> that we
> can't make cross-zone loops work.

I think this is honestly a bit about, should we make the computers more strict 
(and possibly more secure) vs more likely to workaround something that is 
mostly-broken.

Much of the flag day activities were about reducing cruft around workarounds 
for older code out there.  I don’t like breaking existing stuff but am leaning 
towards John in that if people are putting semi-broken glue out there, the 
operator should fix their NS config. 

We have been explicitly driving up DNS queries (eg: QNAME minimization for 
longer zones, like ip6.arpa) for the sake of privacy and reduced performance as 
a result.  I think breaking a few people who have poorly configured systems 
isn’t the end of the world, they will eventually fix their NS records.

Also, trying to define relationships without knowing where the zone cuts may 
exist in a domain is interesting for terminology but not something I believe 
goes in this work.

I think calling out that it’s possible people will create situations where a 
name won’t resolve, is similar to what happens with routing that isn’t 
deterministic as well.  We should be defining how to determinsticly resolve a 
name and highlight that it’s flexible enough you can configure it so it won’t 
work.

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