[DNSOP] Re: Fwd: New Version Notification for draft-ietf-dnsop-zoneversion-10.txt

[Dave Lawrence]

Wessels, Duane writes:
> I’m not sure about this.  Since every zone will have a SOA record,
> and every SOA record will have a serial value, I suppose the question
> becomes whether or not a serial number is “meaningful”.  I don’t know
> how a name server would determine meaningfulness.  

When I first saw Philip's message I had the same reaction, so I went
to the doc to see if "meaningful SOA" was defined previously.  It
wasn't in that specific term, but you did write, "In those cases the
SOA Serial field may not be relevant with respect to the versioning of
its content," which made sense enough for me to understand Philip's edit.

That said ...

> What would be the harm in returning a SOA-SERIAL zone version if it
> were not supposedly meaningful?

Personally I don't see sufficient reason to SHOULD NOT it.


___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values

[Dave Lawrence]

Jim Reid writes:
> IMO documenting the trade-offs in response sizes could be a better
> option. ie if the response > X, it breaks foo; if it’s > Y it breaks
> bar. 

I agree with the approach of limiting discussion of limits to
recommendations.  I am not a fan of enforcing lower limits in the wire
format of what the protocol allows.  I realize the draft is not
currently phrased in terms of enforcing new limits; I'm just staking
my ground.

Also, this draft uses BCP14 boilerplate but only a few instances of
capitalized BCP14 terms; I see two SHOULDs and one MAY.  (Perhaps I
miscounted.)  Presumably it needs more RECOMMENDEDs.

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: Side Meeting - DNS Load Balancing

[Dave Lawrence]

Paul Vixie writes:
> somebody asked me a few months ago why "it's always dns"? meaning,
> why are so  many mysteries and outages ultimately traced down to
> something broken in dns?

Personally, even despite having the relevant haiku as my desktop
background, I push back on this when it rears its head.  I mean, even
ignoring the trouble with absolutes like "always", which can rapidly
be disproven.

The DNS is remarkably robust.  Even when a problem can be "ultimately
traced down to something broken in the dns", it is often not the DNS
itself that was broken.  It frequently did a wonderful job of
providing the answers it was told to provide.  Sometimes it even did
so heroically while under assault.  And, of course, many times the
problematic answers had nothing whatsoever to do with Stupid DNS
Tricks(tm).

So why is it perceived to be "always dns"?  Because the DNS stands at
an incredibly important juncture between people and machines.  That
interface is a concentrator and bound to be where failures on one side
or the other become visible.  That should be the answer to a non-DNS
person asking why it always seems to be the DNS, not harping on the
particular sub-developments that we don't care for.

It can be fun to joke about, but please let's not feed the narrative
that the DNS as a whole is pitifully flawed.  Even with (despite?) the
features that you dislike, it still has done an amazing job as a
fundamental piece of the amazing technological advancement that has
been the Internet.

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

[Dave Lawrence]

Ray Bellis writes:
> I get the impression with DELEG on the horizon that there's a shift 
> towards the parent side data being considered more "authoritative" even 
> though in protocol terms it explicitly isn't.

Yes and no; there's a bit of nuance to ferret out here.  This is part
of the original sin of parent/child NS.  There is no child-side DELEG
for parent-side DELEG to be considered more authoritative about.  It
is just authoritative in the parent in the same way that DS is, which
incidentally is also more authoritative than if you put a DS in the apex.

Your general observation is, of course, correct that yes, this shift
takes a clearer parent-centric view of the perennial parent-centric /
child-centric debate.  In practical terms, operations have largely
been parent-centric anyway.

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

Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

[Dave Lawrence]

Willem Toorop writes:
> Should RFC 8767 stale data be ranked differently than fresh data?
> Should EDNS Client Subnet play into ranking?
> 
> I like your thinking! Yes, fresh data should replace stale data in
> resolver caches

It's basically A- in your draft's hierarchy, I think, though the
current structure gives each letter grade only one type of data for it
and there's already an A-.  However, I am also wondering about the A-
as described, because it seems to suggest that an SOA in auth is less
trustworthy than an SOA in ans.  (Also, A and A- differ in
"authoritative reply" vs "authoritative answer" which are seemingly
describing the same thing.)

I get that you're trying to indicate that NS in auth is lower than
(correctly scoped) NS in ans, but it needs a little finagling, maybe
just to call out explicitly NS rather than generalized data.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

[Dave Lawrence]

Shumon Huque writes:
> The draft allows (but does not proscribe) NXDOMAIN to be inserted
> into the Rcode for non DNSSEC enabled responses. I guess the main
> reason for not being proscriptive was what I mentioned - there were
> deployments in the field that didn't. But I'm amenable to tightening
> up the language if there is consensus for it (and I'll also chat
> with the implementers). Since we also support signaled restoration
> of the NXDOMAIN RCODE field for DNSSEC enabled  queries, I'm
> persuaded that we should probably close this divergence for non
> DNSSEC too.

You already know my position on this, but for the list: yes, please,
do this.

The existence of some deployments that currently do otherwise is
insufficient reason on its own to not specify better behavior.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

[Dave Lawrence]

Shumon Huque writes:
> I've been told the other way is confusing too - we get a different response
> depending on the value of the DO flag. Since it isn't clear to me which way
> is the least worse, I'm fine with leaving the text as is.

Of course, we already get different responses depending on whether DO
is set, independent of this draft...

I realize you are using a much more constrained definition of
"response" here just to mean "response code" but in the larger picture
I don't think it's that relevant to hinge on "things are different
with DNSSEC OK" when things are *already* different with it.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

[Dave Lawrence]

Stephane Bortzmeyer writes:
> > One current implementation does not differentiate DO=0 vs 1 and gives the
> > same NODATA answer for both cases.
> 
> Yes. I see no practical problem with that but, from a philosophical
> point of view, it disturbs me. Naive clients may make wrong
> conclusions from the NODATA answer. 

Very much so, and not just naive programmatic clients but also
non-naive real-life human clients.  I myself have been misled by
noerror/nodata where nxdomain would have been correct.  It's
frustrating.

nxdomain is usefully distinct and auth servers really ought to be
strongly encouraged to return it where applicable.

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

Re: [DNSOP] [Ext] About key tags

[Dave Lawrence]

Mark Andrews writes:
> Ed, your reasoning is off.  The point of forbidding is to allow the
> validator to safely stop as soon as possible when it is under
> attack.

Uh?  Why can't any DNS server safely stop as soon as possible when it
is under attack?

Count me in the "we don't need a protocol change, limiting work is
already there" camp.

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

[DNSOP] Extensible from the start - was - Re: [Ext] Re: DNSOPComments on draft-dnsop-deleg-00.txt - section 1

[Dave Lawrence]

Edward Lewis writes:
> Is there going to be an assumed "standard set" of keywords?

Yes.  Currently it specifies using the Service Parameter Keys
registry:

https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml

> (And a defined manner to know how to deal with
> unknown-to-the-receiver keywords.)

Yes, this needs to be documented.

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

Re: [DNSOP] Documenting DELEG design trade-offs

[Dave Lawrence]

Philip Homburg writes:
> DNSSEC has a lot of moving parts that needed to be in place compared
> to DoH.

Yes, certainly there are many differences between the two, some of
which speak to the challenges of DELEG when looked at through the lens
of DNSSEC.  The core point was that motivation as a factor can't be
overlooked, and DELEG looks to me to have coding and deployment
motivations more comparable to DoH than to DNSSEC.

Some things we deploy quickly on the Internet.  Some things drag.
Declaring at this stage that this will take 10 years to be practical
is an insufficiently supported assertion.

Where there's a whip, there's a way.  Er, where there's a will.
That's the one I meant.

(https://www.youtube.com/watch?v=YdXQJS3Yv0Y)

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

Re: [DNSOP] Documenting DELEG design trade-offs

[Dave Lawrence]

Paul Wouters writes:
> I tried to show some of of these in my "Costs of deleg" slide.
> A new RRtype has a fairly big cost meassures in years, both in
> terms of DNS software, DNS deployment and worse, in Registrar
> deployment for Registrant webui elements.

Unfortunately, I know of no good way to capture motivation as a factor
for coming up with an accurate timeline for expectations.

When DNSSEC came out, I admit I was kind of surprised to see how long
it took to be used.  I thought it would be adopted faster.  There was
insufficient motivation when the system worked well enough and the
problem being addressed was, to many people, largely theoretical.

When DoH was proposed I admit I was kind of surprised to see how many
implementations rapidly came out. I thought it would take
longer. Developers sure were motivated though.  It was addressing
something they really wanted.

You're undeniably right that it takes time, but my own sense is that
"a decade" to have useful deployment is far overstated.  I see more
energy around this from several different quarters of the industry,
with a design that is more easily relatable than tying it into DNSSEC
and DS.  I don't think it's accurate to lump it in as just another new
rr type.

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

[DNSOP] Two points by Joe - was Re: [Ext] Re: DELEG and parent only resolution

[Dave Lawrence]

Edward Lewis writes:
> The impact on the registration system wasn’t raised at the table.

Not entirely true.  We did recognize that there'd need to be an EPP
draft too.

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

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01

[Dave Lawrence]

Mark Andrews writes:
> It’s a couple of lines of code in a nameserver to support QCOUNT=0.
> It will take more time debating this than it took to implement
> support for QCOUNT=0.

Miek Gieben writes:
> yes, please, the amount of code that duplicates checks for
> QDCOUNT!=1 is staggering, and that just in the Golang eco-system.

Well now I'm really a lot more curious about this.

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

Re: [DNSOP] [dnsdir] [Ext] Dnsdir last call review of draft-ietf-dnsop-dns-error-reporting-06

[Dave Lawrence]

> > in responses where there client didn't even use EDNS.  6891 permits
> > this,
> 
> RFC6891 explicitly forbids this with a MUST NOT.

Ugh, you know, this is exactly what I told you in the hall yesterday
but then I actually went and looked when I was writing my last reply.
I wanted to emphasize again, "see, here's one type of response that
shouldn't get this done to it, for a request that didn't include EDNS
at all!"  But then I looked at 6891 and thought, "huh, I was wrong
about it not being allowed."

Now how did that happen? Well because it says MAY up in 6891 6.1.1 on
page 6 but then doesn't get around to saying MUST NOT until six pages
later in section 7.  That's not ideal, but water long under the bridge.

Ugh.  So, like, maybe you could emphasize that it should not be added
in response to non-EDNS requests per 6891.  I'm still not a fan of
saying just a bare "responses" without giving any indication of
what sorts of responses would be expected to have it and which
wouldn't.  I don't think it has to be a hard specification of
allowed/not allowed, even just further description recognizing that
"responses" is broadly scoped and nothing is off the table (other than
the no-EDNS case...)

But if that's just me and I'm shouting at the sea, so be it.


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

Re: [DNSOP] [Ext] [dnsdir] Dnsdir last call review of draft-ietf-dnsop-dns-error-reporting-06

[Dave Lawrence]

Roy Arends writes:
> > Is this a novel risk presented by the proposal?  Any more than, say, a
> > random subdomain attack targeted directly at the agent domain? 
> 
> Nope, not a novel risk, but it was added at the request of some
> security focused folk. 

Fair enough, but out of your own self-interest I think you should note
then that this is not a new risk you're introducing. :)

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

Re: [DNSOP] [dnsdir] [Ext] Dnsdir last call review of draft-ietf-dnsop-dns-error-reporting-06

[Dave Lawrence]

Roy Arends via dnsdir writes:
> Why would you, as an implementor, guess? 

Because you've only said only "responses", and then also provided a
document that largely talked about DNSSEC as examples.  Clarifying
that is not intended only for DNSSEC reporting would be great.

If you really mean "all responses" then say it explicitly.  I think
that's overkill, but at least it is specified.  Protocols should be
clear, and just an unmodified "responses" leaves too much implicit
without any real guidance.

It's noteworthy that you are now suggesting it should be even inserted
in responses where there client didn't even use EDNS.  6891 permits
this, but as far as I can think of this is the first time we are
suggesting that authority servers do that, so it really deserves some
explicit attention.

> > Also, for Section 5, is 0 an okay OPTION-LENGTH
> 
> No.
>> > or must it be minimum
> > 1 with an AGENT-DOMAIN of \0?  
> 
> No.

Right, and I get why ... but it should be explicit.  You have a two
octet field that could represent [0, 65535] but for this spec only [3,
241] are even theoretically usable.

> > "The reporting resolver MUST NOT use DNS error reporting to report a
> > failure in resolving the report query." This feels ambigous to me,
> > because even as an old DNSSEC geek I would, in the vernacular,
> > describe a failure to validate as a failure to resolve.  Short example
> > phrases of what sort of thing you don't want to see happen would be
> > good.
> 
> No.

Okay, yeah, I wiffed on that one.  I totally missed the point of the
sentence and it is clearer to me now.  Whoops.  My bad.

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

Re: [DNSOP] [dnsdir] Dnsdir last call review of draft-ietf-dnsop-dns-error-reporting-06

[Dave Lawrence]

One last bit of wondering I have is about this paragraph from Security
Considerations:

"This method can be abused by intentionally deploying broken zones
 with agent domains that are delegated to victims.  This is
 particularly effective when DNS requests that trigger error
 messages are sent through open resolvers [RFC8499] or widely
 distributed network monitoring systems that perform distributed
 queries from around the globe."

Is this a novel risk presented by the proposal?  Any more than, say, a
random subdomain attack targeted directly at the agent domain? 
  

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

Re: [DNSOP] New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-01.txt

[Dave Lawrence]

I am not in favour of yet another change to DNSSEC bits without a much
larger demonstration of value than what this proposal has.  It's not
that I think this one has no value, I just think that the bulk of its
value is achievable via other mechanisms.

While it is true that there could be more user-friendly pre-delegation
testing, pre-delegation testing is effective.  Making that more
accessible could be achieved on a much shorter timeline than rolling
out these protocol changes.  It's achievable right now.

That said, I do see how this allows for identifying how some
individual validating resolvers might have problems when others
(including the pre-delegation testing tool) would not.  Yet I haven't
seen that scenario be much a real world problem that needs solving.
Even that could conceivably use approaches that do not need protocol
changes, or the expectation that any given domain has enough broad
usage to adequately exercise the testing in the dry-run phase.

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

Re: [DNSOP] The DNSOP WG has placed draft-rebs-dnsop-svcb-dane in state "Call For Adoption By WG Issued"

[Dave Lawrence]

I'm in favour of working group adoption for this draft.  It provides
important clarifications for the interaction of DANE and SVCB.

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

Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call

[Dave Lawrence]

Thanks for the work on this, Stephane, Ralph, and Paul.

Could you please clarify explicitly what should happen in the case of
encountering CNAMEs?  Or DNAMEs?

The way I read it, at least for CNAMEs, is that you just keep
prepending labels to the ANCESTOR name so encountering the CNAME is in
practice no different from encountering any rrtype other than NS.
This would also be consistent with the existing DNS not having any
prohibition of data beneath a CNAME, such that we can fetch data for
foo.bar.example.com even in the presence of a bar.example.com CNAME.

Ralph's original presentation for OARC 24 though had a different
implication on slide 11 that, in the absence of speaker explaining it
to me, implies that encountering a CNAME ... well, I'm not sure.

https://www.nlnetlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf#page=11

With the word "change" there and the arrows it says to me that it's
doing a query restart on the CNAME and continuing onward with the
minimisation algorithm from there.  And it's mentioned right there
with referrals as something parenthetically noteworthy.

How do BIND andc Unbo,und currently handle this?  I'm guessing both like
the way described by the algorithm.

It'd help future implementers to have explicit guidance.  Perhaps
something like:

   (6b)  All other NOERROR answers (either positive or negative).
   Cache this answer.  Regardless of the answered RRset type,
   including CNAMEs, continue with the algorithm from step 3
   by building on the original QNAME.

I changed it to "All other" because 6a is also a NOERROR answer.  I
orthogonally think you should make that change, even if my other text
is rejected.

I'm not feeling great about my wordsmithing, but I made an effort
under the "please send text" maxim.

Or maybe this should just be an unnumbered note at the end of the section,
saying something like:

Note that in this algorithm, encountering a CNAME is no different
from encountering other non-referral positive answers.  They are
not followed when discovered for intermediate labels.  Always use
the labels of the original QNAME.

Then have an example cover this case in section 4, maybe just by using
NOTE to observe it could be "any positive answer, even CNAME".
Doesn't fit on the line well though.

Oh and for DNAME ... maybe in 6a describe that it's also a referral,
one that should set CHILD to the target and resume the algorithm at
step 5?  That seems maybe insufficient, but it's a starting point for
thinking about.

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Dave Lawrence]

I support adoption, with the caveat that either the draft name should
be updated with something like s/powerbind/delegation-only-dnssec/, or
the draft should describe why it is being called "powerbind".

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

Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

[Dave Lawrence]

Thank you very much for your review, Ben.

Benjamin Kaduk via Datatracker writes:
>For a comprehensive treatment of DNS terms, please see [RFC8499].
> 
> (side note: I myself would not use the word "comprehensive" when it
> explicitly says that "some DNS-related terms are interpreted quite
> differently by different DNS experts", but I understand why it is used
> here.)

Would "For a glossary of ..." work better?  Slightly simpler text then too.

>There are a number of reasons why an authoritative server may become
>unreachable, including Denial of Service (DoS) attacks, network
>issues, and so on.  If a recursive server is unable to contact the
>authoritative servers for a query but still has relevant data that
> 
> side note: the way this is worded might make a reader wonder if the
> recursive is expected to attempt to contact all known authoritatives
> before declaring failure.

It's slightly complicated but I'd say "expected to" is yes in the
general sense of it but the devil is in the details.  Most
implementations basically do try all authorities of the set their
working with, but also have safeguards for getting bogged down, like
what is later described as the query resolution timer.  This keeps
them from being tarpitted on an NS RRset that provides many
authorities that all have some sort of aberrant behavior, whether that
be unreachability or super slow TCP or whatever.  This isn't just
theoretical either, but observed in the wild.

Based on that I'd be reluctant to add either "all" into there, or to
fully describe the situation.

>Several recursive resolver operators, including Akamai, currently use
>stale data for answers in some way.  A number of recursive resolver
> 
> I did not follow the discussions that led to this wording, but one of my
> colleagues at Akamai suggested that "currently fall back to stale data
> for answers under some circumstances" might be a nicer wording, though I
> note that Adam has already proposed some text here as well, which is
> probably fine.

Per Adam's review I'd already stricken the mention of Akamai's
operations here.  In the earliest versions of the draft it kind of fit
in more naturally as being one member of a set of other explicitly
named providers, but the latter were implementations rather than
specific operations and subsequent edits separated them out.
Ultimately the call-out to a specific operator (and in particular, the
one I worked for at the time) was more meaningful background when
the draft was first introduced than is necessary to have in there now.

> I recommend using "[this document]" in the section references, since a
> reader reading the updated content in the context of RFC 1035 might look
> there instead of here.

Yes, I had also updated this per Adam's review to have the RFC Editor
adjust accordingly.

> side note: I'm slightly surprised that the semantics of the absence of
> Recusion Desired are not more tightly nailed down, but neither is it the
> role of this document to specify them.

We're barely scratching the surface about what might surprise you that
isn't more tightly nailed down in the DNS. Did I ever tell you about
that time in DoH where we argued for metaphorical days over what TC
really means? 

>When no authorities are able to be reached during a resolution
>attempt, the resolver should attempt to refresh the delegation and
>restart the iterative lookup process with the remaining time on the
>query resolution timer.  This resumption should be done only once
>during one resolution effort.
> 
> Is the "during one" more like a global cap or more like "during a
> given"?

I confess I don't quite understand the distinction you're drawing, so
perhaps a concrete example helps.  The idea to be communicated is that
if you're trying to resolve foo.example.com but your current NS RRSET
for example.com are all having issues (timeout, servfail, whatever)
then you should try to refresh example.com NS again and if any new
servers are learned, go ahead and try them.  If they fail just bail.
How does that square with your thoughts about a global cap?

>The client response timer is another variable which deserves
>consideration.  If this value is too short, there exists the risk
>that stale answers may be used even when the authoritative server is
>actually reachable but slow; this may result in sub-optimal answers
>being returned.  Conversely, waiting too long will negatively impact
>user experience.
> 
> Not just sub-optimal but potentially even wrong or actively harmful
> answers, no?

True, that's in the bounds of possibility and not well-encapsulated by
the understated "sub-optimal".  s/sub-optimal/undesirable/?
Undesirable does a better a job of incorporating wrongness but is
still subtle.  Or would you prefer s/sub-optimal/sub-optimal, wrong,
or even actively harmful/?  Is the latter not covered adequately by
the Security Considerations section?

Realistically 

Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

[Dave Lawrence]

Thank you for the review, Roman.

Roman Danyliw via Datatracker writes:
> * I agree with Mirja, Section 8 is more informative than what is
> alluded to the paragraph starting with “Several recursive resolvers
> …” in Section 3, and IMO is worth keeping.

I've already updated the GitHub copy in response to Mirja's review to
drop the request for the RFC Editor to remove the section.

> I struck me as odd to call out the operation practice of a
> particular vendor (Akamai).  We might want to check if this
> reference is ok – Ben?

I had also removed this reference from Section 3.  It was important
background material when I first introduced the draft, before the
technique became more widely available, but I agree that Akamai
specifically need ongoing highlighting there.

> * A few reference nits:
> - Section 6.  Per the mention to DNS-OARC, please provide a citation.

This was my own personal research on DITL data, not published as a
special report.  How should I cite?

> - Section 6 and 9.  The text references “during discussions in the
> IETF”.  What is that specifically – WG deliberation?

Yes, in dnsop (mostly at the mic, as I recall).  It used to say dnsop
specifically (version -05) but a couple of people had stronger
feelings than I that the language there should use the more expansive
IETF umbrella.  Me personally, my only strong feeling on the matter is
that, though someone else has suggested that it just be excluded
entirely, I want to see it included as historically relevant because
we did spend time on the EDNS option issue only to have it ultimately
be decided that it wasn't wanted.

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

Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

[Dave Lawrence]

Thank you very much for your review, Adam.  I have incorporated your
feedback into the document (which is not yet pushed to datatracker).

Here's the diff:

https://github.com/vttale/serve-stale/commit/3ae0f4e5f79e0b326608beaa77b74a1efe62663c

Adam Roach via Datatracker writes:
> The addition of what I must presume is intended to be RFC 2119
> language to a document that doesn't cite RFC 2119 seems
> questionable.  I would suggest either explicitly adding RFC 2119
> boilerplate to RFC 1035 as part of this update, or using plain
> English language to convey the same concepts as are intended.

I definitely agree it is questionable, and if something needs to be
done to resolve this then your first suggestion is the one that is
more agreeable to me personally, but I can also see how that too is
questionable and might get some pushback.  It's a bit of a weird
situation. 

It is perhaps worth noting that several other RFCs that have updated
1035, starting with 3658, have already used 2119 normative keywords.
So in spirit it's already there, just not with an explicit remark in
any of the that formally puts the boilerplate on 1035 itself.  (And,
in the end, that means 1035 is a weird hodge-podge of old world and new.)

> >  A proposed mitigation is that certificate authorities
> >  should fully look up each name starting at the DNS root for every
> >  name lookup.  Alternatively, CAs should use a resolver that is not
> >  serving stale data.
> 
> This seems like a perfectly good solution, although I wonder how
> many CAs are likely to read this document. If I were the type to
> engage in wagering, I'd put all of my money on "zero." I'm not sure
> specific action is called for prior to publication of this document
> as an RFC, but it seems that additional publicity of this issue and
> the way that serve-stale interacts with it -- e.g., to CAB Forum and
> its members -- is warranted.

Completely agree, except to the point that if it were known that there
was money riding on it then someone at a CA would read it just to take
your money. :)  That said, anyone have thoughts on how best to bring
it to their attention?

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

Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

[Dave Lawrence]

Dave Lawrence writes:
> We had a lot of back-and-forth in the working group about
> normative language in this document, and but for the Standards Action
> section.

Huh, I clearly had a slipping brain clutch in the middle of that
sentence when it came to the final phrase.  I think I had intended to
finish the sentence something like "... determined it was best to not
use normative keywords."  Apologies for my failure to proofread before
sending.

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

Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

[Dave Lawrence]

Thank you very much for your review, Mirja.

> 1) It seems to me that this sentence in section 7 should/could
> actually be phrased as a normative requirement in this document: "it
> is not necessary that every client request needs to trigger a new
> lookup flow in the presence of stale data, [...]"

I agree.  We had a lot of back-and-forth in the working group about
normative language in this document, and but for the Standards Action
section.  I'm personally in support of more of it, but ended up having
to strip out existing instances of normative language based on working
group consensus.

> 2) I find the Implementation Status section (8) actually quite
> interesting for this document and maybe it should be considered to
> keep it in the document for final publication.

I personally am in favor of this, not just for this document but for
all RFCs.   RFC 6982 recommends that the section be removed, but I'd
be happy to help evolve that recommendation.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

[Dave Lawrence]

Benjamin Kaduk writes:
> Isn't there still some latent risk of such fielded implementations
> that would be incompatible with this change if it ever did show up
> on the wire? 

There's always some risk with any change, right?  I'm not trying to be
flatly dismissive of the concern. I do, however, find vague,
unsubstantiated concerns about the behaviour of unidentified software
to be a poor basis for an engineering decision.

Given that no circumstance has been identified where this is an issue,
the next best thing is a risk analysis of the potential, and I've
previously gone over the possible failure scenarios.  The worst case
identified is that someone was actually sending a negative TTL with
the intent of it being cached as 0 (leaving open the question about
why they'd make that choice), but which would now be treated by new
software as very large and almost universally capped at something more
sane but still on the order of days instead of an augenblick.  

As failure cases go, my subjective opinion is that this is not vexing,
especially without any evidence that someone is making meaningful
operational use of the treat-as-zero logic.  If they were, it seems to
me that the people running the authority doing that and needing the
dynamic remapping it implies would be highly incentivized to update
their relatively smaller footprint of servers to behave more
reasonably.

On the flip side, authorities sending an obnoxiously large TTL (2^31+)
would now get the expected behviour of being cached as long as
possible rather than 0.  Of course I personally would expect them to
get their act together and send more sane TTLs, too, in no small part
because in practical terms there are smaller values they could use to
achieve the same aims without having to even deal with the question of
the high order bit.  The risk on this end is that new software,
written with the expectation that 2^31+ TTLs would be treated as
basically equivalent to 2^31-1 and then capped by modern resolvers,
might send to an old treat-as-0 resolver and get surprisingly frequent
requeries for what the operator intended to be a static response.  If
this traffic were for a popular enough name to cause packet volume to
rise above the usual noise in any sort of remotely problematic way,
the authority operators are then highly incentivized to change as
well.  This is all hinging on a lot of "ifs" though, starting that
chain with it being new behavior by an authority to start sending such
TTLs.

If you see some greater risk potential, I'll gladly think on that some
more.  I certainly don't want to cause any harm either; I just don't
see it here.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

[Dave Lawrence]

internet-dra...@ietf.org writes:
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-09

This revision addressed the one remaining outstanding issue that Brian
Carpenter raised in the Gen-ART Last Call Review.  The following text
was added to explain why a TTL with the high-order bit set is now
handles as a large positive number (then capped down) rather than a
negative number (and treated as zero).

As for the change to treat a TTL with the high-order bit set as
positive and then clamping it, as opposed to [RFC2181] treating it as
zero, the rationale here is basically one of engineering simplicity
versus an inconsequential operational history.  Negative TTLs had no
rational intentional meaning that wouldn't have been satisfied by just
sending 0 instead, and similarly there was realistically no practical
purpose for sending TTLs of 2^25 seconds (1 year) or more.  There's
also no record of TTLs in the wild having the most significant bit set
in DNS-OARC's "Day in the Life" samples.  With no apparent reason for
operators to use them intentionally, that leaves either errors or
non-standard experiments as explanations as to why such TTLs might be
encountered, with neither providing an obviously compelling reason as
to why having the leading bit set should be treated differently from
having any of the next eleven bits set and then capped per Section 4.

I also removed the phrasing about 2181's handling of this issue as a
"curious suggestion".  I recognize it could have an unintended
negative connotation against the original authors, though when I wrote
the sentence originally I meant it only with its neutral denotation.
It was curious to me only because no rationale was provided as to why
that particular choice had been made, despite the current assertion
that it was obvious as to why.

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

Re: [DNSOP] draft-ietf-dnsop-serve-stale: lightly-suggested ranges

[Dave Lawrence]

Paul Hoffman writes:
> Greetings again. draft-ietf-dnsop-serve-stale has a few places where
> it suggest ranges for values, but these suggestions are vague.

"Vague"?  They give hard numbers with the intended flexibility for the
considerations that might go into them.

> Could be:
>   Values SHOULD
>   be capped to 604,800 seconds, and implementations SHOULD allow
>   lower values to be configured by operators.

Do we really have to suggest to implementers that this be
configurable, especially when all of the major packages already have
such a knob, afaik?

> Could be:
>When returning a response containing stale records, the recursive
>resolver MUST set the TTL of each expired record in the message to a
>value greater than 0, with 30 seconds RECOMMENDED. Implementations
>SHOULD allow values above 0, but SHOULD NOT allow values greater
>than 600 seconds.

This one looks useful, suggesting a reasonable cap on the order of
minutes rather than much longer.  I'm happy to make the change.

>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 value SHOULD be
>one day, and SHOULD NOT be longer than 3 days.

All 2119 normative language was removed from that section.

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

Re: [DNSOP] draft-ietf-dnsop-serve-stale: returning stale answers when faced with SERVFAIL responses

[Dave Lawrence]

Paul Hoffman writes:
>However, implementations MUST NOT send stale data if they have received
>any answer from an authoritative server.

I personally strongly disagree with this.

ServFail is a signal from the authoritative operator that something is
amiss, and is in practical terms is not really distinguishable from
being unable to reach them. It's not just a "funny answer".  If the
resolver was previously able to get good answers for the same query
but is now getting the server declaring things are whack, I don't see
how passing through the ServFail helps anything, and it harms the
intended resiliency of this whole endeavour.

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

Re: [DNSOP] ANAME high-level benefit question

[Dave Lawrence]

Brian Dickson writes:
> Have any "closed system" implementations of non-standard apex-CNAME
> hacks, committed publicly to neutral ANAME operations, presuming
> ANAME as currently envisioned?  I.e. If each such provider will
> ONLY support ANAME with targets on their own infrastructure, I don't
> think the standardization effort will have any real value.

I have a related question ... is allowing only targets on their own
infrastructure currently a limitation most such providers have?

I can't speak to Akamai's plans for implementing ANAME, but can say
that one of their apex-CNAME features allows any name to be used as a
target.  Their other feature allows only a subset of names on their
platform to be a target but that's an efficiency issue, not a policy
one, and I would expect their handling of ANAME to use that method
when appropriate or fall back to the general case otherwise.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-05.txt

[Dave Lawrence]

Davey Song writes:
> Normally end user have more than one configured resolvers. If only
> one resolver experience the outage and serve the stale data, could
> the user tell which resolver have more refreshed data ?

Not in the usual resolution process, no.  Whether the user's system
will fall back to the second resolver in a "reasonable" amount of time
depends on local policy.  Of course, it's entirely possible that the
second resolver won't have any better answer anyway, either because
the answer hasn't changed, it has changed but provides essentially the
same service level, or the second resolver is experiencing the
same network path problems as well.

Even if it were communicated from the recursive resolver to the stub,
then there is a further matter of communicating that to the end user.
The complexity of this led to a clear sentiment in dnsop against
including mechanisms to mark an answer that used stale data.

So yes, serving stale data is not always the best result, but
operational experience has shown that on balance the observed
benefit has outweighed the possible negative by far.

> 2) I notice it is proposed as a stand track document. If more people
> here think its benefit outweighs its impacts, I prefer it published
> as informational document

This was discussed early on, and the rationale for standards track is
that it is well within the scope of a standard to clear define
acceptable data lifetime.  While the details of each implementation
are indeed informational, being clear that data can legitimately be
used in an error condition beyond the time the TTL says it is normally
valid is properly part of the definition of a TTL.

> 3) A minor concern: in an thread in dns-operation mailing list last
> week, it is said that the behavior of serve stale in some ISPs is
> abused for reason of traffic hijack/tampering/spoofing. I'm afraid
> it will be encouraged by this document.

Two things are of note here:  they're already doing it even without an
RFC blessing it, and the document lays out pretty clearly that this is
not the condition for which serve-stale should be used.

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

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Dave Lawrence]

On Tue, Mar 26, 2019 at 12:48 PM Tony Finch  wrote:
>> I think the suggested max stale timer of 7 days is excessive. The aim is
>> to cope with an outage, so I think 1 day is much more reasonable (though I
>> have configured my servers with a 1 hour limit).

Olli Vanhoja writes:
> I agree. At least based on my own experience, all the network or other
> downtime issues I have experienced last only few minutes. 

Okay, I agree a little that 7 days is probably excessive as a
recommendation, though not harmful.  I also agree that in most
instance where serve-stale has already proven itself to be useful, 
the events are fairly short-lived.

On the other hand I have direct operational experience that says if a
problem is being caused not by a generalized DOS or other transient
network issue, then it can indeed take multiple days to resolve.
Start of a long weekend?  Trying to reach the right people to fix it?
Surely you've experienced customers not responding quite as quickly to
fix their problems as you'd like.

So I'm not so keen on one day, but could see dropping the
recommendation to 3.  It is, after all, still just a recommendation
and one that should be configurable.

> If there is a downtime longer than that and it's only affecting DNS,
> I would seriously consider changing my service providers and
> vendors, whatever is the issue.

Right!  But in the meantime, until that change is done ...

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

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Dave Lawrence]

Ray Bellis writes:
> Serve stael must not become a vector whereby malware can keep its C 
> systems artificially alive even if the parent has removed the C domain 
> name.

I wholeheartedly agree with this ideal, and am very open to
considering text improvements.

The document already has guidance on this point, but it is admittedly
in a considerations section and not in standards action, and is a
weaker "SHOULD" versus "MUST" right now.

Would the WG prefer that a line like this be put into the Standards
Action section?

  When no authorities for a name are able to be reached, the resolver
  MUST attempt to refresh the delegation.

I like the basic idea but am a little stuck on the wording because of
the endless loop it implies.  This is probably why it appears as
"SHOULD" already (but I honestly don't remember, so there's that).

It seems to me that the risk is very low, even as currently written in
the draft.  Not only do I have a lot of confidence in the implementers
of the most widely used resolvers in the world, as they're right here
participating too and have in the past shown good conscientiousness in
this area, but the practical attack is still hard to make meaningful.
If "the parent has removed the C domain name" as you said,
serve-stale shouldn't even kick in.  NxDomain, problem solved.

Various other scenarios come to mind, even with obstinate parents that
won't remove the delegation and the zone's NSs have gone dark, but
those scenarios have other possible remedies.  And fast flux using
long TTL NS RRsets are an issue no matter whether serve-stale is in
play or not.

So text regarding refreshing delegations could be given even more
words to describe backoff intervals and such, but to what end?  What's
the scenario?  And wouldn't it be handled better by reviving
resimprove to talk about the generalized problem?

(To be clear, I'm quite okay with politely being shown that I'm wrong
and there is a vector by which serve-stale becomes uniquely
interesting, and would certainly endeavour to make sure it is addressed.)

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

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Dave Lawrence]

bert hubert writes:
> I too object.  This is partially due to the apparently unresolved IPR issue
> from Akamai, who are known not to be shy asserting their IPR.

This is definitely a problem.  Even though Akamai had previously
agreed to specify under what IETF-acceptable terms the IPR would be
made available, it clearly hasn't yet specified them.  I've contacted
them to get a timeline on when the legal department can take care of
this, and the first order response is that the DNS team is trying to
get the ball rolling again with legal this week.

> My secondary objection is that the draft contains an example
> implementation that then however uses normative words. This leads to
> pain with operators demanding serve-stale compliance. Example
> algorithms should clearly be examples and not tell us what we SHOULD
> do.

As previously noted in this very thread, at least one of the authors,
Puneet, agrees with you.  When I wrote the text that way it was
because of the also not-unreasonable viewpoint that if someone were to
be implementing the example then the text could be considered
normative as to how to do that.  It's even softened by having no MUSTs
at all, just SHOULD.  In addition, I'm dubious as to the claim that
people would cause meaningful pain to demand compliance with an
example, and not be adequately refuted when it is pointed out to them
that it is a clearly marked as an example.

That said, since I had waffled on it myself at time of composition and
I don't actually have a very strong feeling about it, in the end
wouldn't fight over downcasing it.  Yet I think it should be settled
at a level above dnsop because ultimately it's an issue that should be
consistent across IETF documentation.  Unless there's already an
explicitly stated IETF policy about this, and not just ad hoc past
cases to point to, I think it is best to sort out with the RFC editor.

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

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Dave Lawrence]

Paul Vixie writes:
> i would withdraw that objection if this draft incorporates section 2 of 
> https://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00, to wit:

I always liked resimprove.  Warren and I were talking about it, and if
you would like we'd be quite happy to pick it up and get it moving in
dnsop.  

This document already has text, however, for refreshing the delegation
and I don't believe it really needs to much detail as to what that
means.  "Delegation Revalidation Upon NS RRset Expiry" is an issue
orthogonal to serve-stale, and in fact most often applies when
serve-stale isn't even being triggered; it's a regular occurrence
under normal operations.  Ballooning the standards action section here
to nearly three times its existing size is unnecessary bloat.

Please let us know if you'd like us to take up the charge for
resimprove.

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

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Dave Lawrence]

Thank you very much for the feedback, Jinmei.  

Combined with previous changes we made following the other messages on
the draft we expect to republish it before the Monday IETF 104
submission deadline, after one last review by all of the co-authors.

Jinmei:
>> The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is
>> amended to read:
>>
>>TTL  [...]  If the authority for the data is unavailable
>>when attempting to refresh, the record MAY be used as though it is
>>unexpired.
> 
>   On understanding that this is the only real normative description,
>   I'd suggest making some more points explicit to prevent abusing of
>   this leniency:
>   - explicitly say "all authoritative servers" instead of just "the
> authority"
>   - also explicitly note that this MUST NOT be allowed if at least one
> authoritative server is available

I can see how the phrasing of "if the authority" could imply to a
novice in the DNS space that only one server would be tried, so I
updated the wording to:

 If the data is unable to be authoritatively refreshed when the
 TTL expires, the record MAY be used as though it is unexpired.

I think this phrasing is sufficient without needing to explicitly say
all servers and must not if at least one responds.  Existing resolver
implementations are extremely thorough in trying to get authoritative
answers and it is extremely hard to imagine that anyone would take
this draft to mean that they should be any less thorough.

>   - clarify whether this means a 0-TTL record can be cached and reused
> under this condition (I assume it must not, but it's not very clear
> to me)

Added this to the caveats section:

 The continuing prohibition against using data with a 0 second TTL
 beyond the current transaction explicitly extends to it being
 unusable even for stale fallback, as it is not to be cached at all.

>>   If it finds no relevant unexpired data and the Recursion Desired
>>   flag is not set in the request, it SHOULD immediately return the
>>   response without consulting the cache for expired records.

>   It would be nice if it clarified *what* to return in this case (if
>   it's intentionally left open, explicitly say so).

Added:

 Typically this response would be a referral to authoritative
 nameservers covering the zone, but the specifics are implementation
 dependent.

I was surprised to discover when testing against BIND 9.12 (without
serve-stale in play) that dig +norec for an unknown example.com name
gave a referral to com, even when it knew the NS for example.com
either via the parent delegation or even from the apex.

>>   Outside the period of the resolution recheck timer, the resolver
>>   SHOULD start the query resolution timer and begin the iterative
>>   resolution process.
> 
>   It's not clear to me how this timer is related to the 'server-stale'
>   behavior; [...]

I think it's main utility in the example method is to emphasize that
even if you send a stale answer to the client while a lengthy
resolution attempt is still playing out, you've got to keep trying.
Admittedly capping the work of that lengthy attempt is not
specifically relevant, but as you noted this is an example.
I can see your point about possibly simplifying by removing a few
sentences related to it, but as I also think that capping work is an
important aspect of resiliency I'm inclined to leave it in.

>   this draft doesn't explain what happens when this timer
>   expires, for example.

Based on "This timer bounds the work done by the resolver
when contacting external authorities" I'd have thought it was
implicitly clear, but I have added:

 If this timer expires on an attempted lookup that is still
 being processed, the resolution effort is abandoned.

> Also, in my understanding unbound doesn't have this timer - it
> eventually gives up a resolution if all possible external query
> fails with a per-query timeout, but it doesn't cap the overall
> resolution time.

Interesting.  I know of an Unbound-derived server that definitely caps
work, though that may have been local changes and not incorporated
into mainline.  Tarpitting was a significant issue for the people
involved.

>> Stale data is used only when refreshing has failed, in order to
>> adhere to the original intent of the design of the DNS and the
>> behaviour expected by operators.
> 
>   I agree on this statement, but I wonder how widely this behavior is
>   actually implemented.  As noted in Section 7, unbound doesn't behave
>   this way, and in my understanding it's intentional, mainly due to
>   a concern about related IPR.

Huh, My understanding from a hallway conversation with Benno was that
the immediate response is only sent for names that would have been
subject to pre-fetching, such that the immediate response in this case
is sufficiently covered under the guidance of a recent attempt being
made.  If that is not the case, and you can get stale answers from

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt [and 1 more messages]

[Dave Lawrence]

Jinmei:
> I also found it confusing on my fresh re-read of serve-stale-03 in
> that the "example method" section contains normative descriptions
> using RFC2119 keywords.

You're in good company in that co-author Puneet has voiced the same
opinion.  

My own take is that it's appropriate because if someone were to go
ahead and directly implement from the example method, then the BCP 14
normative language is appropriate because they are requirements of the
example method.  But that's only my viewpoint without knowing of any
further existing editorial guidance on the matter, and your point is
also sensible in favor of downcasing them as not being BCP 14
"requirements in the specification" in a broader sense.

I'm inclined to leave it to the RFC Editor to adjudicate as to what's best.
Ultimately I'm not passionate about it either way.

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Dave Lawrence]

Joe Abley writes:
> if you can find a set of DNS authority servers that silently
> discards a particular kind of query, sending such queries through
> resolvers that are known to support serve-stale might suppress other
> queries and trigger the serve-stale behaviour even though the
> authority servers are not actually unresponsive for them.

RFC 2308 section 7.2 made it clear that when caching a dead server
indication, "The indication MUST be stored against query tuple  unless there was a transport
layer indication that the server does not exist, in which case it
applies to all queries to that specific IP address."

The scenario described in one of a resolver that is modern enough to
have implemented standards-compliant serve-stale behavior but is still
not standards-compliant with a two decade old RFC, interacting over a
path with a delegation to authoritative servers that are all
exhibiting erratic behavior.  This needs some supporting evidence that
it could really be a real-world problem that needs to be addressed.

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Dave Lawrence]

Tony Finch writes:
> This sounds like it will lead to stale answers being given instead of
> re-trying other potentially working servers.

The document is explicit that you need to keep trying to get an
answer, so if an implementation is not retrying other potentially
working servers that is its own defect.

> I think serve-stale should only cover cases where servers are
> unreachable or unresponsive.

You are of course free to write your own implementation that way.
Having worked for operations where the authorities were concerned
about the possibility of accidental ServFails, I know that their
preference is that resolvers would serve-stale then too and enhance
the overall resiliency of the system.

If you think it would help, I can add some text to Implementation
Considerations about this, something like:

   Consider whether serve-stale should kick in for only the case of
   all servers being unresponsive, or whether authoritative servers
   responding with DNS RCODEs other than NoError and NXDomain also
   trigger it.  Some authoritative servers operators would prefer
   stale answers to be used in the event of their server failures,
   while other implementers see any answer from the authoritative
   server as being sufficient indication that any previously available
   answer for the question is superseded.

The implications of that are a transition from good answers to
failure answers to unavailable means that the stale answers will never
be available when they otherwise could have been, but so be it.

> If all a zone's servers start to reply REFUSED, that's a deliberate
> decision to disable the zone, and resolvers should not try to keep it
> alive beyond its TTL.

You cannot know that it is a deliberate decision to disable the zone.
In fact, I have direct operational experience of why it's a terrible
way to disable a zone.

One of my own servers was slammed for queries in a zone I was not
authoritative for.  (It was a well-known zone, too, and one which is
not DNSSEC-signed.)  My server was dutifully returning Refused to the
queries, and yet they kept coming very frequently, maxing the
link. Arguably the clients should have applied the techniques of RFC
2308 for negative caching of those Refused answers, but it was not
until I added the zone in question to send back an authoritative
answer with a proper caching signal that the queries really went away.

While it is obviously the best approach for a takedown to update the
delegation, in the situation where you have a delegation pointing to
server(s) that cannot be updated but you have control over the
servers, it is far better to provide an affirmative answer to the
question than to send Refused.  Positive caching is much better
understood than negative caching by the wide variety of DNS
implementations out there.

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Dave Lawrence]

Tony Finch writes:
> If the zone has a mixture of lame and working servers, the lame servers
> should not trigger serve-stale, because the resolver still needs to try
> asking the working servers.

Yes, complete agreement.  That is the thrust of what the document says.

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Dave Lawrence]

Christopher Morrow writes:
> My point is that the recursive reoslver has no idea why an authoritative
> is unreachable and that doing anything like sending stale records is 
> going to cause unintended problems.

Given the operational benefit that has already been observed in
production with serve-stale, I think it needs more than vague fears of
"is going to cause unintended problems" to argue against it.  If we
let unspecified concerns of possible unintended problems be our
guidance we'd never get anything done around here.

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Dave Lawrence]

Paul Wouters writes:
> I am a bit confused here. The goal of the draft is to keep data past
> the TTL in case you cannot reach the authoritative servers during a
> DDOS attack.

There are many different failure modes in operating the DNS and
the goal of this draft has been to accommodate the ones that are clear
failures.  I, for one, have never put forth that it is only about
resiliency against DDoS and don't recall hearing Warren or Puneet say
that either.  It can include when there are other clear errors in
the system, even when self-inflicted by the authoritative operator.

> Misconfiguring your authoritative server by removing the zone is not
> meant to be covered by this draft if I understood it correctly. If it
> is, then introduction will need to add text to cover that use case.

I can sort of see how someone might infer from "It is predicated on
the observation that authoritative server unavailability can cause
outages ..." that it means this whole idea is constrained to DDoS, and
presumably you would include as well other network and server outages
not caused by DDoS.  It doesn't only mean that though.  The intention
is that this applies to any inability to get a proper authoritative
response, one which has AA set in a protocol-meaningful way.

This can be edited to be clearer, perhaps as simply as changing
"authoritative server unavailability" to "authoritative answer
unavailability".  We'd be happy to consider alternative text.

Realistically only rcodes NoError and NXDomain apply for being
authoritative answers, each being an explicit assertion regarding the
name/type in the query and legitimately supplanting whatever previous
data was known about that name and type.

ServFail is a clear signal that something is going wrong with the
authoritative server itself has something going wrong.  If you send a
ServFail then AA is completely irrelevant.

REFUSED is slightly murkier as to its exact meaning, thanks to
overloading, but in its most commonly seen usage for lameness
indicates a clear problem with the delegation.  Even in its other use
cases, notably an EDNS Client Subnet error or an actual "I am
authoritative for the name but administratively denying your
resolution of it", I submit that if the resolver has a stale answer
then serving it is reasonable.  In that administrative denial case
it'd be better to issue NXDomain anyway, which is exactly what split
horizon authorities do.

Other lesser seen rcodes are largely similar in not indicating
anything at all about the legitimacy of the name and whatever data you
might have previously associated with it.  Only the dynamic update
rcodes come close to being relevant, but they are not part of the
resolution process covered by serve-stale.

Despite the unfortunate RFC 1035 nomenclature of NXDomain as "Name
Error" it is called out explicitly because it isn't really an error,
not in the database lookup sense.  There's no way of knowing whether
the NXDomain is happening because of operator fault or the far more
likely case that it just doesn't exist.  That's why it is called out
separately in the doc, with an explicit note about why it has to be
treated as replacing any stale data associated with the name.

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Dave Lawrence]

Paul Wouters writes:
> In the non-DDOS case, the auth server is reachable and none of the data
> is getting additional TTL added:
> 
> Answers from authoritative servers that have a DNS Response Code of
> either 0 (NOERROR) or 3 (NXDOMAIN) MUST be considered to have
> refreshed the data at the resolver.  In particular, this means that
> this method is not meant to protect against operator error at the
> authoritative server that turns a name that is intended to be valid
> into one that is non-existent, because there is no way for a resolver
> to know intent.
> 
> Although perhaps it should also explicitely state this regarding
> ServFail ?

I personally have a very strong opposition to including servfail.
Servfail is an extremely clear indication that the authority that was
contacted is having some sort of structural problem.  It is a very
distinct condition from being told by the authority that the name does
or does not exist.

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Dave Lawrence]

Paul Vixie writes:
> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> > can I ask, what happens when a domain is intentionally down though? For
> > instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
> > master/shadow NS go down, hard. All public auth servers eventually (in a
> > day or so) went dark too.
> 
> i already raised that question, very far up-thread. got no answer.

While my answer to it was significantly late for when the query was
made, and for that I have previously and will again apologize, it was
responded to:

https://mailarchive.ietf.org/arch/msg/dnsop/2o62EmB35OiBKNq9YZLfSMpqL2U



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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt [and 1 more messages]

[Dave Lawrence]

Paul Hoffman writes:
> I'm not sure a standards track document that updates RFC 1034/1035
> should be recommending a minimum TTL. 

As previously noted, we're making no such recommendation and that will
be clarified.  The first definition of "resolution recheck timer" in
section 5 does already say that it regards failed lookups, but it
seems that adding that distinction later is also warranted.

> The document is actively confusing about recommendations.

Before we go pushing around whole sections of text, could anyone
please comment on whether they find it "actively confusing about
recommendations"?  Yes, they appear in a couple of different sections,
for different reasons -- as described in the text the example method
presented is just one possible way of doing things, with the core idea
and the standards-relevant changes being distinct.

The recommendations, however, are not in conflict with each other and
I'm really not clear myself on where the criticism that they are
confusing comes from.  The mention of the explicit word "recommended"
in section 6/6.1 is just reiterating the value described in section 5,
and in the broader sense of recommendations section 6.1 is meant as
how the recommendations were made.  (Personally I'd renumber 6.1 -> 7,
7 -> 8, etc, but  that's a minor separate issue.)  Putting that
discussion in a separate discussion doesn't bog down the basic
description of the sample implementation.

I don't object to reorganization in principle, if it makes notable
gains, but I can't really fix what I don't understand the problem is.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Dave Lawrence]

Bob Harold writes:
> Will the "resolution recheck timer" cause ttl's less than the timer
> to be effectively lengthened, by refusing to look them up again?  I
> think 'serve-stale' should focus on the situation where the auth
> server is not available, and not change the handling of short ttl's.
> Or am I mis-reading that?

Mildly misreading, though it does point out that we could make it
clearer that this is akin to existing mechanisms that resolvers have
to cache that an authority is problematic (eg, RFC 2308 Section 7).
It is NOT about the feature that some resolvers also have, a minimum
cache TTL, which is what you're concerned about and we don't intend to
address in this document.  As you say, and unfortunately we somehow
managed to not make clear, the purpose is only to deal with failures
to refresh authoritative data.

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

Re: [DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt

[Dave Lawrence]

Thanks very much for the review, Mukund!  Puneet has already
incorporated the editorial feedback into the GitHub copy.

Mukund Sivaraman writes:
>>  "It is predicated on the observation that authoritative server
>>   unavailability can cause outages even when the underlying data 
>>   those servers would return is typically unchanged."
> 
> While reading this, I wonder whether the last sentence was meant to be
> written as: "It is predicated on the observation that zone data returned
> by authoritative nameservers during a resolver refresh would typically
> be unchanged."

I agree that it's a reasonable rephrasing, and I'm wondering if you
see that there's a practical difference.  Not that I'm particularly
wed to the original text, just wondering if I'm missing something
either in grammar or semantics that makes the rewrite superior.

> >issues, and so on.  If the recursive server is unable to contact the
> >authoritative servers for a name but still has relevant data that has
> 
> s/for a name/for a query/

Puneet made this change, but I'll observe that since names are how
authoritative servers get delegated, I think "servers for a name" is an
acceptable, natural way to refer to the process.

> It is a curious thing why it was decided that [TTL] values with the
> high order bit set are not clamped but set to zero. Possibly because
> it can be thought that such high values are bogus and assumed to be
> made in error, and so a resolver should attempt to re-query such
> records instead of caching them for a very long time. OTOH, one can
> think the same of a TTL=2147483647 answer too. :P

Yeah, I don't know the reasoning and haven't searched the dnsext
archives to see if there was discussion on it back in the mid-90s when
the treat-it-as-zero clarification was decided.  Neither zero not 2^31
seem like good ideas really, and the issue will be in the presentation
to dnsop today.

> This option seems to me too complicated to generate, parse and make use
> of. RRs are re-ordered very late during message rendering in some DNS
> implementations, and updating this syntax in the EDNS option just looks
> too painful. It does not appear parsing (by resolvers) will be easy
> either, and whether this fine granularity in determining staleness is
> generally useful.

I do agree that it is somewhat more complicated, but I'm not sure
about "too complicated".  My thinking when I first offered it is that
if I'm using an option for diagnostic purposes, I want explicit
information returned.  So for something like "dig +any +edns-stale
example.com" (or whatever) when I'm debugging, I can count off the
indices well enough.

I would not expect automated systems that receive the option to really
care much about specifically what RRSets were stale, if they were
concerned about staleness at all.  And if they do care ... they can
count off the indices well enough too.

Here's another fun idea, to specifically identify the relevant parts
of the message:  name compression pointers!  Okay, okay ... yeah it
makes me feel a little skeevy too.  

On the other hand you could also iterate over each name/type with
either recursion disabled or the other EDNS option, so there's that
way of dealing with diagnostics too.

> Would it be better to limit fetches by the resolver for 30 seconds,
> while still returning TTL=0 answers?

It's an interesting though, but besides my general wariness of TTL 0
records I do note that this would mean keeping more state in the
resolver than it currently has to keep, and when I think about how I'd
implement that in BIND at least there's a fair bit of complexity there.

> Do all implementations mentioned earlier supporting the idea of this
> draft attempt to refresh stale data before serving it? Does this draft
> prescribe if resolvers SHOULD/MUST do so? Because the two approaches
> result in quite different behaviors.

To the best of my knowledge, no, though hopefully I've missed news on
an update to Unbound.  My understanding about how Unbound does it's
feature is that it's basically "shoot first and ask questions later".
That is, I think it'll use any data from the cache first, stale or
not, before trying the resolution.   That's part of the reason that I
wrote explicitly in the draft about honoring the intent of the TTL and
using stale data only in unusual circumstances.

> I think some implementations of this draft do not implement the client
> response timer, and so waiting for the query resolution timer (which may
> be a large duration) may result in application getaddrinfo() timeouts.

That would circumvent pretty much the whole intent to add resiliency
for clients waiting for answers.

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

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

[Dave Lawrence]

Dave Lawrence writes:
> Count me as another, for that very reason.  When I first saw Paul's
> message I thought, "oh that's a shame" but figured it to be fairly
> set.  If there's flexibility for making the meeting happen earlier in
> the week, I'd be interested.

Following up to my own message, since this was further down in my box
on another list...

--- start of forwarded message (RFC 934 encapsulation) ---
From: Paul Hoffman 
Subject: Re: [ksk-rollover] Informal meeting at IETF 103
To: "ksk-rollo...@icann.org" 

Based on some requests from folks who are leaving the IETF meeting
early, I have also reserved a meeting room for 1600-1700 Wednesday
afternoon (local time), Pagoda Room on the 4th floor.

And just to emphasize: the purpose of this week's informal gatherings is
to let folks in the IETF community chat about their ideas in front of
other IETFers. This is similar to the KSK-related mic lines at the
DNS-OARC and RIPE meetings a few weeks ago. These IETF side-meetings
really are just slightly-better-organized hallway discussions. Given the
wide range of proposals we have already heard, it is good to get a bit
of face-to-face sharing going early.

We won't start formal planning about the KSK futures until after the
rollover process is complete*. When we do, we'll do it in discussion
environments that are much more inclusive than these informal IETF
side-meetings or the mic lines at other technical meetings.

[...]
--- end ---

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

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

[Dave Lawrence]

Joe Abley writes:
> I'm sure I'm not the only person planning to fly out from Bangkok on
> Friday morning, given that there are no working group meetings
> scheduled on that day.

Count me as another, for that very reason.  When I first saw Paul's
message I thought, "oh that's a shame" but figured it to be fairly
set.  If there's flexibility for making the meeting happen earlier in
the week, I'd be interested.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-02.txt

[Dave Lawrence]

internet-dra...@ietf.org writes:
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-02

Here's a summary of the functional updates:

Puneet Sood @ Google added as co-author in the short-lived -01.

A second, simpler EDNS option for signaling is proposed for
discussion.  That makes:

  * Option 1: Capable of identifying exactly which RRSets are stale so
that a stub can use that information to handle each exactly as
desired.

  * Option 2: Simplified to only indicate that stale data appears in
the answer, but not where.

A discussion note for the updated TTL definition, that "capping values
with the high order bit as being max positive, rather than 0, is a
change from [RFC2181]. Also, we could use this opportunity to
recommend a much more sane maximum value like 604800 seconds, which is
one week, instead of the literal maximum of 68 years."

Raised the suggested response TTL on stale records to 30 seconds, from
1 second.  That's in the message from the recursive to its client.

Recommended that refresh attempts from the recursive to the
authorities happen no more frequently than every 30 seconds.

One thing I've realized isn't mentioned in the draft but maybe should
be is that even in the absence of an EDNS option stale data can also
be disabled by the client request if it asks without the recurse flag
on (dig +norec).  Since serve-stale as proposed relies on recursion
failing, if there was no attempted recursion that could have failed
there will be no revisiting the cache to find stale answers.

   

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

Re: [DNSOP] state management related to TTL

[Dave Lawrence]

Paul, apologies for taking nearly a year to recall this message and
respond to it:

https://www.ietf.org/mail-archive/web/dnsop/current/msg21367.html

I'll trim down citation material for response, but that's not to mean
the parts I am not responding to are ignored.  For example, I pretty
much agree with the first five paragraphs.

The first part that jumps out to me as bearing further discussion
starts here:

Paul Vixie writes:
> another method that's been deployed of avoiding simultaneous "don't
> have" with "great need" is to liberally reinterpret TTL such that
> RRsets can be reused beyond their explicit TTL lifetime, while their
> refresh queries proceed in the background.  commonly, the authority
> servers responsible for answering these refresh events are down or
> unreachable at the time of most acute need.

Here "in the background" implies to me that there is a perception that 
the stale answer is given preference to refreshing the data, so to be
clear that is not the case.  The draft is explicit that an attempt
should be made -- in the foreground -- to refresh before falling back
to stale data.  It is therefore used in exceptional circumstances, and
I also would not be inclined to describe the unreachability of
authorities as "commonly".  Operational experience bears this out.

> the danger of TTL stretching is that reuse beyond TTL may cause
> RRsets that are in fact supposed to be unreachable, to be
> effectively reachable. examples include security-related takedown of
> criminal DNS servers or networks, or failover strategies where end
> systems will not try to reach their backup servers unless they
> cannot reach their primary servers, and the unreachability of those
> primary servers is hidden from them by TTL
> stretching. fundamentally, an RRset and its TTL are the property of
> the zone administrator, and it's controversial for any other party
> to use this data beyond its specified use parameters.

This is the meat of this message to me.  Can you please elaborate on
the scenarios where this takedown situation is a problem?  What are
the circumstances by which a takedown is only able to be effected
through some mechanism which would be subverted by serve-stale?
Removing the delegation still works, as does repointing the
delegation, or rerouting the authority addresses, or physically taking
over the authorities and thereby being able to change their answers.
The only scenario that I can imagine it not working is when you can
physically disable links to the to-be-disabled authorities but have
none of the other remedies available.  Is this something that happens?

I know you don't mean to say this, but it's also hard not to have it
come to mind that this sounds a bit like "we can't do this because bad
people might use it to their advantage."  Maybe, but beyond the
question of how, does that sufficiently outweigh the benefit
non-baddies can get?  We have lots of technology that bad people can
use to do bad things.  It's really hard to evaluate that without more a
detailed look at the threat model.

Similarly, I'm wondering about these other existing systems that rely
on unusable primary delegations to fix those delegations to point to
backup servers, especially with the typical TTLs in TLDs being the
dominating consideration for actually being able to cause the
failover.  That's not to say I doubt such systems exist, because of
course the DNS is constantly monitored by any reasonable
provider. Every such monitoring system with which I have personal
experience has many checks than would not be impacted by serve-stale.
I'm specifically interested in learning more about the systems for
which serve-stale causes breakage, and how they might end up getting a
stale-serving resolver without an affirmative administrative choice to
install and enable the feature in such a resolver for such a
monitoring system.

> most of us recognize that TTL's will continue to be stretched no
> matter what changes are or are not made to the specification, and so
> we expect the resulting RFC to document current practice _without
> recommending it_ and to also document a new practice _with
> recommendations_ as to its proper uses.

I think you'll need more support for the assertion that "most of us
 expect".  Based on the conversation that's happened around this so
far, and with my best attempt at fairly evaluating feedback both on
the list and in person, my own impression is that most implementers
and operators with whom I've spoken are supportive of the immediate
resilience benefit of serve-stale as described in the draft.

> noone has proposed any new signaling between the stub and the
> recursive, but it's possible that a stub may want a true TTL and so
> we might add signaling from the stub (as initiator) saying, don't
> stretch, or perhaps saying, if this is a stretched TTL, tell me so
> explicitly.

The draft that predated your message by a couple of weeks proposed the
functionality whereby a stub could 

Re: [DNSOP] SRV and HTTP

[Dave Lawrence]

Dave Lawrence writes:
> Mark Nottingham writes:
> > I'll start collecting. How about Tuesday, say 6:45-7:45pm?
> 
> Last session ends at 6:20 and social starts at 7, not sure how late
> the last bus (if any?) will be leaving the hotel.

Nevermind, walking distance to social, under 1km.  Maybe still though
shifting it a little earlier, like 18:30.

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

Re: [DNSOP] SRV and HTTP

[Dave Lawrence]

Mark Nottingham writes:
> I'll start collecting. How about Tuesday, say 6:45-7:45pm?

Last session ends at 6:20 and social starts at 7, not sure how late
the last bus (if any?) will be leaving the hotel.

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

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Dave Lawrence]

Joe Abley writes:
>but collapsing the address selection back to the extent that you can
> avoid name resolution at all seems like a better end goal. 
> 
> So rather than resolverless operation, think about resolutionless or
> nameless, eliminating the DNS as unnecessary overhead. 
> 
> Perhaps I have misunderstood the whole problem space, of course :-)

I believe you are spot-on.

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

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Dave Lawrence]

Tim Wicinski writes:
> "Are you trying to re-invent DNSSEC for people who don't want to deploy
> DNSSEC?"
> 
> My magic 8-ball says "signs point to Yes"

I don't grok how y'all got "trying to re-invent DNSSEC" out of this,
so this is sure to be an entertaining discussion.

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

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Dave Lawrence]

Paul Vixie writes:
> > For example www.example.com  pushes you a 
> > record for img1.example.com . Should you use
> > it?
> 
> no. sibling names might be delegation points. kashpureff taught us this 
> in 1996 or so, and kaminsky reinforced that lesson in 2008.
> 
> > What if it is for img1.img-example.com ?
> 
> certainly not.

In the large I agree with you, but I think there's more to it than
that.  If it pushed me DNSSEC records that I could verify myself from
my own configured trust anchor, why can't I trust them then?


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

Re: [DNSOP] re original_transport indicator

[Dave Lawrence]

Martin Thomson writes:
> I think that a better choice is message/dns.

I personally prefer this to dns-udpwireformat / dns-wireformat

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Dave Lawrence]

Martin Thomson writes:
> Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
> concede that I'm probably missing something.

I think that's right.  -05 with the original_transport optional
parameter accommodates the aims of that other draft.

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

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Dave Lawrence]

Martin Thomson writes:
> If I understand your response (not sure that I do), that seems pretty
> academic and not at all persuasive.  For instance, if a client cared
> about testing TCP capabilities, it can always do its own resolution.

That testing TCP capabilities part is a distraction from the core
motivation.  The request makes sense from a dumb transparent proxy
point of view, where there's a regular DNS resolver on the one end who
just wants to be able to get DNS messages through an HTTPS tunnel.
Media type isn't the right way to achieve that, but the key idea is sound.

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

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt

[Dave Lawrence]

Davey Song writes:
> To keep the transparency of DOH proxy, the proxy server should use
> the same transport as the proxy client receive queries from
> stub-resolver, transports patterns like UDP-DOH-UDP, and
> TCP-DOH-TCP. So the proxy client should signal the proxy server the
> initial transport recieve from stub-client.

I'm really not digging this as a good use of a media type, especially
when the draft says:

  "If proxy client receives the query via TCP, then it
   will carry a new media type defined in this document "application/
   dns-tcpwireformat" and speak DOH with proxy server with the same
   DNS query without the two-byte length field defined in DNS over
   TCP"

So, dns-tcpwireformat and dns-udpwireformat are byte-for-byte
identical on the wire, and you're just using it as a signal for the
transport you want the DOH Proxy Server to use when talking to a
resolver (if indeed it is talking to separate resolver at all), is
that right?  If a transparent DOH proxy client is talking to a
co-operating DOH proxy server, shouldn't they have a better signaling
mechanism than that?  Is there any other media type that directs a
server on transport issues?

The use case also doesn't really address why it is important to
preserve the stub's udp-vs-tcp choice to its presumptive resolver, but
rather only refers only vaguely to the transparency issue.  It would
be nice to have a clearer statement of what's driving this proposal.

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

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt

[Dave Lawrence]

Davey Song writes:
> Is a media type "application/dns-tcpwireformat" acceptable

Without yet having (re-)read the draft, I'm unclear on what benefit
this media type is bringing over dns-udpwireformat, since the only
difference presumably is explicitly adding the two octets of a
content-length <= 65535.  Is it something other than that?

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

[DNSOP] Notice to dnsop: doh @ IETF 101

[Dave Lawrence]

Please be aware that at the doh meeting on Thursday afternoon in
London there will be a summary discussion of the state of
https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/
with the expected outcome being soon moving it on to working group
last call.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

[Dave Lawrence]

Paul Vixie writes:
> i'm of the opposite view. we should not change behaviour without 
> explicit signaling. if that means it takes 10 years to reach 50% 
> penetration, like EDNS did, then that's the cost of doing business.

Just so I'm clear, am I understanding correctly from this that you
believe a recursive server should only fall back to stale data from
cache if the request explicitly included a staleness option?

I ask because Bob's comment that started this thread was exploring
being able to signal staleness back when OPT was included in the
request but the option being defined by the draft wasn't included.

To me this makes three different positions we're trying to reach
consensus about, for allowing fallback to stale either:

1) when the request explicitly signals it is ok;
2) when the request groks EDNS but might or might not understand
   a staleness option; or
3) in all cases.

My current understanding is that you and Paul are of position 1, while
I'm at 3.  At first glance 2 would appear to be pretty nearly the same
as 3 as far as its permissive toward unaware clients, but
significantly it does at least provide signal you could still access
via protocol debugging (dig, tcpdump, etc).

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

[Dave Lawrence]

tale:
>> It is significantly less operationally beneficial if it demands EDNS.

Paul, and echoed by Paul:
> i'm of the opposite view. we should not change behaviour without
> explicit signaling.

I've opened this as an issue to track toward WG consensus and suspect
that, unless strong consensus for one view or the other obviously
emerges on the list, that we'll be looking for a hum on it in London.

On the practical side, private implementations are of course going to
easily evade any MUST that could eventually make its way here and
still be seamlessly interoperable with clients.  The restriction's
effect would mainly be binding for implementations claiming the
strictest compliance.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

[Dave Lawrence]

Alexander Mayrhofer writes:
> I'm torn on the question whether or not stale data should be served
> (without signaling, in that case) when the request does *not*
> contain an OPT request.

I'm personally not torn on this; for me the whole point of
implementing this functionality is to add resiliency to the existing
DNS ecosystem.  Very specifically for my implementation it was needed
in an environment where answers were going to a stub resolver that did
not (and still does not) speak EDNS.

It is significantly less operationally beneficial if it demands EDNS.

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

Re: [DNSOP] Clarifying referrals (#35)

[Dave Lawrence]

Evan Hunt writes:
> Okay. I haven't encountered a resolver that propgates REFUSED from the
> authority to the stub.  If there is such a beast, then IMHO that, not the
> authority, is the one that's mis-using REFUSED; REFUSED only makes sense on
> a hop-by-hop basis.

Very much agree.  I'd be surprised to see REFUSED from a resolver.

Now on the other hand, using extended-error for signalling from a
resolver that the known authorities all returned REFUSED, that's
interesting and can be made unambiguous as a code apart from the
currently proposed extended-error 4, "Prohibited".

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

[Dave Lawrence]

Bob Harold writes:
> I am a little concerned about yet another option that the client
> might want to send with every query.  Can the existence of *any*
> EDNS option from the client be taken to mean that EDNS options are
> understood in general, and the resolver is ok to respond with this
> ENDS option, which the client might not understand but will not choke on?

I personally am of the belief that yes, if the request has an OPT then
a responder can include an option code that was not in the request.
At least I don't see anything in 6891 to prohibit it.  This is
behaviour that draft-ietf-dnsop-extended-error is also expecting.

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

Re: [DNSOP] DINRG update

[Dave Lawrence]

On Nov 13, 2017, at 8:12 AM, Melinda Shore  wrote:
> With regrets to the fine folks of dnsop, we've scheduled the
> dinrg side meeting from 9:30 - 12:00 this morning.  We realize
> that there are many people in the dns community who are
> interested in decentralized approaches to naming but scheduling
> during this meeting has been exceptionally difficult.

Given that the Thursday dnsop slot from 15:50-17:50 has been
cancelled, is there interest in having another get-together then?

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

[Dave Lawrence]

Dave Lawrence writes:
> The main changes, based on previous feedback, are:
> 
> * Clarifying what the action is for Standards Track;
> * Describing the algorithm previously proposed (and still included) as
>   one example way of achieving the goals; and,
> * Adding a rough proposal for an EDNS option that could be used for
>   explicit signalling.
> 
> That last item will be fleshed out more if there's demonstrated
> interest from implementers in having such a thing.

At the moment I'll observe there are no open issues against the draft,
which is my comically passive-aggressive way of pointing out that it
is obviously perfect and so let's just move it along to Last Call.

This is now your opportunity to correspondingly observe that someone
is wrong on the Internet and to respond appropriately.  At the very
least, we'd like to know whether there is sufficient support for
pursuing the EDNS option or just to take it back out (and leave the
rest of the obviously perfect document as-is).

Thanks in advance for any feedback,
tale

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

Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt

[Dave Lawrence]

internet-dra...@ietf.org writes:
>   Title   : BULK DNS Resource Records
>   Filename: draft-woodworth-bulk-rr-07.txt

Changes are here:

https://www.ietf.org/rfcdiff?url1=draft-woodworth-bulk-rr-06=draft-woodworth-bulk-rr-07

The primary differences are to add a bit more text on the motivating
use cases to the introduction (not just for "wallpapering IPv6 reverse
space") and to remove the proposed Numeric Pattern Normalization
DNSSEC record from this particular draft.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

[Dave Lawrence]

internet-dra...@ietf.org writes:
>   Title   : Serving Stale Data to Improve DNS Resiliency
>   Filename: draft-ietf-dnsop-serve-stale-00.txt

This is the same as draft-tale-dnsop-serve-stale-02, only renamed for
WG adoption.

The differences between -01 and -02 are here:

https://www.ietf.org/rfcdiff?url1=draft-tale-dnsop-serve-stale-01=draft-tale-dnsop-serve-stale-02

The main changes, based on previous feedback, are:

* Clarifying what the action is for Standards Track;
* Describing the algorithm previously proposed (and still included) as
  one example way of achieving the goals; and,
* Adding a rough proposal for an EDNS option that could be used for
  explicit signalling.

That last item will be fleshed out more if there's demonstrated
interest from implementers in having such a thing.

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

Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt

[Dave Lawrence]

Bob Harold writes:
> I don't understand this section:
> 
> 5.1.1. On-the-fly Signatures
>  ...
>One possibly mitigation for addressing the risk of keeping the zone
>signing key online would be to continue to keep the key for signing
>positive answers offline and introduce a second key for online
>signing of negative answers.

How dreadfully embarrassing.  I'm responsible for that.  It was an
underdeveloped thought about how multiple keys can possibly be used in
a zone to sign different answers.  Clearly in the form it made it into
the draft it's a bit nonsense.  My apologies.

It's kind of orthogonal to the main thrust of the BULK proposal though
so I expect this bit will just disappear in the next version.

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt

[Dave Lawrence]

On 7/4/17 6:13 AM, Paul Wouters wrote:
>> Although, we should also be a bit careful not to create a new ANY
>> type query that will get abused for amplification, so it should
>> really all have source verified IP transports (DNS-COOKIES, TCP, etc)

Ray Bellis writes:
> I'd rather not constraint this to source verified transports.
> 
> There's a limit of 7 additional QTYPEs in the draft, which could be
> trivially reduced to 3 (with little effect on the functionality) if that
> would mitigate concerns about amplification.

I very much agree with Ray about not constraining it like this.

While for my own imagined use cases three is adequate, such as for
querying MX, A and  simultaneously, I also don't see any
compelling reason to drop it from his proposed seven.  In my own
scheme I had planned on using a NSEC-like type bitmap, but having
spoken with Ray about this a while ago I know he's not keen on that.

To me the focus on answer size amplification is misdirected.  I am far
more concerned about packet count than packet size, and in any event
constraining this option to only verified channels makes it
immediately less useful.

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt

[Dave Lawrence]

Ray Bellis writes:
> This is just a "keep alive" so as to keep this draft in consideration as
> one of the multiple solutions in this problem space while DNSOP decides
> whether this is a problem worth solving.
> 
> I still think it's the most elegant of those proposed ;-)

I whole-heartedly agree, as Ray's idea was the basic conclusion I'd
arrived at independently.  I was going to propose something very
similar (with only minor differences in details) until I found out
that I'd somehow overlooked his previous draft.

Note that I'm saying this even though I am also now working with
Warren and Wes on the multiple-response draft, which I suspect is one
of the other proposed solutions that Ray implies above.

I believe that multiple-response and multi-qtypes solve similar but
somewhat different problems.  As Wes observed during a conversation
last week, the former is for when the authoritative server believes it
knows what records you're going to want next (and even then can't
effectively signal the absence of any particular record).  The latter
is driven by the client knowing just types it'll want to know about
for a given qname, and indicates explicitly what the existence of each
is.

Multi-qtypes is also far easier to implement and will be much more
useful much more quickly.  It can roll out in resolvers and
authorities incrementally without depending on DNSSEC and with far
fewer security concerns.  At a recent industry meeting I announcement
my intention to ask Ray to revive it and was met with fairly
widespread support from both authoritative and recursive operators.

I'm strongly behind multi-qtypes and will be proselytizing for it as
well as contributing text.




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

Re: [DNSOP] comments on draft-tale-dnsop-serve-stale-00

[Dave Lawrence]

Thank you for the feedback, Jinmei!  Now that Akamai finally posted
its IPR notice we can work on moving it forward.  We plan on asking
for WG adoption now that -01 is up.

https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/

Jinmei wrote:
> - I suspect it should include 'Updates: 1035 (if approved)' in the
> top boilerplate.

Done.  1034 too.

>   The recommended value of the client response timer is 1.8 seconds,
>   so end clients will see this amount of delay for queries for which
>   this technique is needed (most notably while the corresponding
>   authoritative servers are under a DoS attack and unreachable).  I
>   wonder whether this is really acceptable in terms of user
>   experience.  According to the draft this implementation has been
>   actually used in the field (correct?).  If so, were the end users
>   okay with the delay?

It's hard for me to address directly what "okay" is.  I can only say
that they got service when otherwise there would have been done.

We're certainly open to discussing timer values.  In fact, Warren has
previously told me that he doesn't think the values are right either.
We might end up with some different recommendations based on
particular use-cases.  At any rate, they're all "SHOULD" for people to
adjust for whatever their own reasons.

>   Also, it's not clear to me why the TTL is set to 1 second.  Since
>   it's actually expired, a zero TTL seems to be a more sensible choice
>   here (a similar feature of unbound uses a zero TTL).  If there's a
>   specific reason to avoid 0, it would be better to explain it
>   explicitly.

Added to document:

"1 second was chosen because historically 0 second TTLs have been
problematic for some implementations.  It not only sidesteps those
potential problems with no practical negative consequence, it would
also rate limit further queries from any client that is honoring the
TTL, such as a forwarding resolver."

Also, as noted with the other timers, it's still a SHOULD.

It doesn't seem worth it to me to add even more text cataloguing the
problems that some people have encountered with 0 TTL, such as
informally described in
http://mark.lindsey.name/2009/03/never-use-dns-ttl-of-zero-0.html

I am, however, still open to further discussion on whether there is a
compelling reason to use 0 instead of 1.  I realize 1035 did have a
pretty explicit definition of what it though 0 *should* mean, but then
went on to describe sending 0 TTL SOAs, which no one does.

> - Section 4
> 
>> Canonical Name (CNAME) records mingled in the expired cache with
>> other records at the same owner name can cause surprising results.
[...]
>   I suspect this is quite specific to internal implementation details
>   of BIND, [...] it's probably better to clarify it's specific to a
>   particular implementation architecture.

I struggled with how to incorporate this feedback, because I felt like
it was already pretty clear that I was discussing BIND specifically.
In the end the only change I made specifically about this was to say
"The version of BIND" instead of just "BIND", because I'm not even
sure whether it would be an issue in the latest versions.  I also
swapped the sequence of events around to match the real incident that
happened (A was received first, then later CNAME, versus the original
doc saying CNAME then A).

If people think there is additional wording improvement still needed
here, please suggest.

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

Re: [DNSOP] draft-tale-dnsop-edns-clientid

[Dave Lawrence]

On 30/03/2017 09:52, Bob Harold wrote:
>> Just a thought - would it be better to have two different EDNS0 options
>> that carry an IP, or to have one EDNS0 option that carries both an IP
>> and a 'type', and allow multiples of that option in a packet?

Ray Bellis writes:
> IMHO, two options is better.

I'm with Ray on this, both because of his earlier observation re: TXT,
and also because this complicates the option design and adds yet<
another number registry.

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

Re: [DNSOP] draft-tale-dnsop-edns-clientid

[Dave Lawrence]

Ray Bellis writes:
> It's effectively the same argument about TXT records - there's plenty of
> things that use TXT format, but it's preferred that separate RRTYPEs are
> used to indicate the use case.

If that's the position the WG would like to take, I'd be fine with that.

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

Re: [DNSOP] draft-tale-dnsop-edns-clientid

[Dave Lawrence]

Ray Bellis writes:
> I therefore think there's a simple test here: [...]

Well yes, but there's another simple test, the limited Expert Review
guidance against duplicate functionality.  Both xpf and clientid
provide the functionality of conveying an IP address in an EDNS0
option.

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

Re: [DNSOP] [Errata Rejected] RFC7871 (4736)

[Dave Lawrence]

RFC Errata System writes:
> http://www.rfc-editor.org/errata_search.php?rfc=7871=4736
> Status: Rejected

>  --VERIFIER NOTES--
> Internet Software Consortium occurs only in the acknowledgements and
> while incorrect now it is generally the perogative of the authors to
> include in this section what they see fit. were a future version to
> be updated it's acknowledgements would probably include the then
> current contributors not the previous ones.

For the record, I would have been fine with the change.  I wasn't the
one who added the text originally, but as someone who worked for ISC
before the renaming, I probably glossed over the name dozens of times
without noticing it needed updating.  I don't know if process-wise it
is allowable as an errata, but apologies nonetheless for the error.

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

Re: [DNSOP] draft-tale-dnsop-serve-stale

[Dave Lawrence]

Paul Vixie writes:
> speaking of resimprove, i hope you'll include in this draft the idea of
> using delegation-TTL as a delegation-recheck interval, and using an
> authoritative NXDOMAIN from the delegator as proof that you need to run
> an "rm -rf" in your cache.

I definitely like the latter idea as wholly on-point for the main
issue this draft is trying to address, and will get it into the next
rev.

I'm slightly less sure about dragging delegating rechecking into it,
but open enough to being convinced that it is also on-point and
doesn't unduly complicate what is conceptually very straightforward in
the current draft.

I'm also in favour of revivificating resimprove.  I don't know why it
languished either, but don't recall substantial objection.  If it were
brought back that somewhat obviates needing to bring up the delegation
recheck here.

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

Re: [DNSOP] draft-tale-dnsop-edns-clientid

[Dave Lawrence]

Peter van Dijk writes:
> On 28 Mar 2017, at 16:35, Dave Lawrence wrote:
> > I grant that there is reason for pause because both Nominum and
> > OpenDNS have squatted code points which have duplicate functionality.
> 
> Should this squatting perhaps be documented in the style of RFC 8093 to 
> avoid future surprises?

Yes, I think that's a good idea.

> > Speaking of Ray's draft, our proposal is able to handle his use case
> > but unfortunately our use cases are not achievable in his. 

> Please note that neither draft handles the use case of also passing the 
> port number, which in a world of growing CGN deployment, may soon prove 
> quite important.

I agree that neither handles it explicitly.  Ray's singular use case
doesn't really need it, and our draft can handle ports through the DNS
address family mechanism if needed, albeit less compactly that could
be otherwise envisioned.  If this were something that others think
should somehow be made explicit via some other mechanism, I could see
incorporating that.

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

Re: [DNSOP] draft-tale-dnsop-edns-clientid

[Dave Lawrence]

Ray Bellis writes:
> I'm somewhat philosophically opposed to anything that injects client
> related information such that it's shared between different parties.

Understandable.  I honestly have similar reservations.

One thing that clouds this a little, as far as our draft is concerned,
is that the ISP's CPE already knows this information so in a sense it
isn't that a different party is being informed.

What I'm trying to accomplish with this draft is acknowledge the
practical realities that this sort of option is already in use on the
Internet and will continue to be used no matter what the WG does about
either of our drafts.  I also wanted to drag the PII issues out into
the open, into one place where they would have to be confronted by
implementers and operators.

I fear that a splintered effort on including full client-identifying
information in several different ways is going to lead to problematic
fragmentation and harder management.

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

Re: [DNSOP] draft-tale-dnsop-serve-stale

[Dave Lawrence]

Pieter Lexis writes:
> I feel that the authors should attempt to describe the goal of the
> algorithm and suggest possible limits and describe pitfalls rather
> than describing the exact algorithm to use.

I confess I'm a bit flummoxed by this comment, as I believe the
document already does describe goals and pitfalls.  If you believe
there is something missing, please let us know what else should be
included.

> This will allow implementers to come up with new and innovative
> algorithms based on continued measurements.

As with how the process went for refuse-any, we'd be happy to consider
including alternative mechanisms.

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

Re: [DNSOP] draft-tale-dnsop-edns-clientid

[Dave Lawrence]

Olafur Gudmundsson writes:
> Strictly speaking the draft was never formally submitted via IANA. 

This is part of the problem with documentation.  At least one natural
entry point for the process, the IANA assignments page, doesn't
indicate how to initiate expert review.

https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11

It does link to RFC 6891 and to RFC 3604 Errata, but that's poor
usability even if those documents described how to initiate review,
which they don't.

> As expert I do not have any formal guidelines to tell me how to
> judge options. My rule after implementing ClientSubnet is $,1r|(Bnever
> again$,1r}(B allow complex type.

Agreed that you have poor guidance, the closest thing is from the
RFCs mentioned above, which only says:

  "Assignment of Option Codes should be liberal, but duplicate
   functionality is to be avoided."

I grant that there is reason for pause because both Nominum and
OpenDNS have squatted code points which have duplicate functionality.

There is a larger philosophical discussion that should be had about
this, though, given that it seems to encourage just totally
circumventing IETF/IANA.  It is ironic to me that I was trying to do
the right thing, yet the process which is supposed to have made
getting option code assignments easier and not require action by the
working group has seemingly failed at that task.  The feeling of
failure is exacerbated by not being able to have expectations properly
set by documentation other than "be liberal".

As for whether this is a complex type, that's a whole separate
discussion to have if the draft itself gets more discussion.  Mostly
here in this message I'm focused on process.

> As Expert I do not want to write the rules for myself :-) 
> I will be happy to comment on any suggested rules/advise. 

Fair enough.  Anyone else interested in working on better guidance?
To be clear, I'm totally okay if the result of that is something that
would have still resulted in an initial denial for this option
assignment under Expert Review.  It's the process I want to see
improved.

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

[DNSOP] draft-tale-dnsop-edns-clientid

[Dave Lawrence]

One of the two drafts I wanted to talk about at dnsop today for WG
adoption was "Client ID in Forwarded DNS Queries":
https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/

The core idea of this document is to be able to provide
device-specific identification in an EDNS option sent to a
full-service resolver, with the principal motivation to be for
filtering products.  It uses an IANA Address Family value to indicate
the format of the identifier that is being sent.  One of the design
goals was to avoid creating any new registries.

This document treads on controversial grounds because of the obvious
privacy implications.  It must be noted that both Nominum and Cisco
are already doing this via EDNS options, and so the general idea
confronts some similar issues we've encountered before about whether
to document in-use protocols or let them just continue on with little
to no public documentation.

As Sara commented on Ray's draft that proposes a very similar option,
draft-bellis-dnsop-xpf, this sort of thing clearly needs a close look
at privacy, and I whole-heartedly agree.  I've already been directly
poking privacy-concerned individuals for feedback.

Speaking of Ray's draft, our proposal is able to handle his use case
but unfortunately our use cases are not achievable in his.  I'd
welcome joining up.

The one other thing I wanted to mention in the WG is that I tried to
get an EDNS code point assigned through the "Expert Review" process,
which it turns out is very poorly documented for either process or
review criteria.  The Expert Reviewer, Olafur Gudmundsson, has
initially denied the request pending feedback from the WG.  I'll leave
it to him to state what gave him pause, and to request the feedback he
seeks.

The denial triggered a bit of a philosophical debate between us, but
no matter which side of that debate you line up on it's very clear
that Expert Review really needs documentation to appropriately set
everyone's expectations.  I'm hoping that he and I will be
collaborating on a draft.

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

[DNSOP] draft-tale-dnsop-serve-stale

[Dave Lawrence]

One of the two drafts I wanted to talk about at dnsop today for WG
adoption was "Serving Stale Data to Improve DNS Resiliency":
https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/

In short, this describes a method for increasing DNS resiliency by
treating the inability to refresh data after TTL expiration as a soft
error, eventually becoming a hard error if the authoritative server
failures are not remedied.

This basic algorithm has been in use at Akamai for six years now and
helped us avoid numerous incidents.  I'd implemented it in BIND and
the patches were recently contributed to ISC.

There are relevant patents in the area held by Google and
Akamai/Xerocole.  I'm still waiting for the official statement from
Akamai lawyers about it, but given that we contributed to the code to
ISC for release under the Mozilla Public License I don't expect any
really issue here.

Warren and I are hoping for WG adoption.

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

[DNSOP] New Version Notification for draft-tale-dnsop-serve-stale-00.txt

[Dave Lawrence]

FYI.

Some of you may be aware that there are at least a couple of patents
in this area (US8972580 and US8832283), and we'll be handling them
through the usual IETF IPR disclosure process.

--- start of forwarded message (RFC 934 encapsulation) ---
From: 
Subject: New Version Notification for draft-tale-dnsop-serve-stale-00.txt
To: David C Lawrence , Warren Kumari 
Date: Mon, 13 Mar 2017 14:04:34 -0700

A new version of I-D, draft-tale-dnsop-serve-stale-00.txt
has been successfully submitted by David C Lawrence and posted to the
IETF repository.

Name:   draft-tale-dnsop-serve-stale
Revision:   00
Title:  Serving Stale Data to Improve DNS Resiliency
Document date:  2017-03-13
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-tale-dnsop-serve-stale-00.txt
Status:
https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/
Htmlized:
https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-00

Abstract:
   This draft defines a method for recursive resolvers to use stale DNS
   data to avoid outages when authoritative nameservers cannot be reached
   to refresh expired data.

Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

The IETF Secretariat
--- end ---

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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Dave Lawrence]

Paul Hoffman writes:
> Is there a community of zone admins who want this so much that they 
> won't start signing until it exists?

I think that question is a little extreme and need not go that far to
determine whether something is worthwhile to pursue.

My interest in NSEC5 is largely around the significant performance
gains it has over NSEC3-WhiteLies, with double the throughout reported
in "Can NSEC5 be Practical for DNSSEC Deployments"
.

We have a large number of zones that are not yet signed, and a
non-trivial part of that is because of performance.  NSEC5 has an
impact in addressing that issue.

Professionally, I'm somewhat less concerned about the enumeration
issue because the at least some of the zones where I want to use it
have highly structured names anyway.  Enumerating them is trivial even
in plain old non-DNSSEC DNS.  In the other, less-structured zones that
we already sign we use classic NSEC3 and are considering going to
NSEC3-WL on behalf of customers that do care about it. We have online
ksks for other features required of these zones.

On a personal level I appreciate that this proposal enhances ksk
security while addressing the enumeration problem.

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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Dave Lawrence]

Phillip Hallam-Baker writes:
> There are two reasons for splitting out the VRF [...]
 
Thanks, Phill!  Those were our thoughts as well.  Though the VRF
appendix is still included in -04, the VRF document has already been
started.  It is planned that the appendix will disappear (to be
replaced with examples of different nsec5 responses) and the VRF
document incorporated by normative reference.

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

[DNSOP] Client ID in Forwarded DNS Queries

[Dave Lawrence]

FYI.

--- start of forwarded message (RFC 934 encapsulation) ---
From: 
Subject: New Version Notification for draft-tale-dnsop-edns0-clientid-00.txt
Date: Wed, 15 Feb 2017 13:56:46 -0800


A new version of I-D, draft-tale-dnsop-edns0-clientid-00.txt
has been successfully submitted by David C Lawrence and posted to the
IETF repository.

Name:   draft-tale-dnsop-edns0-clientid
Revision:   00
Title:  Client ID in Forwarded DNS Queries
Document date:  2017-02-14
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/internet-drafts/draft-tale-dnsop-edns0-clientid-00.txt
Status:
https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/
Htmlized:
https://tools.ietf.org/html/draft-tale-dnsop-edns0-clientid-00


Abstract:
   This draft defines a DNS EDNS option to carry a client-specific
   identifier in DNS queries, with guidance for privacy protection of
   such information.

Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

The IETF Secretariat
--- end ---

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

Re: [DNSOP] naming and shaming broken implementations

[Dave Lawrence]

On 22 Jun 2016, at 11:13, Stephane Bortzmeyer  wrote:
> It is not "fun", it is the only way to have broken implementations
> (Akamai, djbdns) fixed. If we do not name them, they will continue forever.

Even ignoring the loaded "shaming" terminology that Jim added to this
thread, I still have to disagree a bit.  It is not the only way, and
certainly there is brokenness that gets fixed without publicly
pointing fingers.

For example, in the case of the conceptual failure of the Akamai
nameserver to properly identify empty non-terminals in all necessary
answer-seeking paths, this was a problem that I noted internally a
decade ago.  Yet it was triaged well below other work because it had
no practical operational impact at the time and fixing it was
non-trivial.

Only when the qname minimisation draft came around did it really
become an operational issue, and the priority of the change request
was immediately raised.  No one needed to point out to us either that
we had the problem or that operational evolution made it matter.
Working on fixing it was going to happen regardless.

As to why it has taken so long, the public deployment of a fix was
delayed when we discovered that some customers actually relied on the
non-compliant behaviour.  Believe me, I was frustrated by this
probably more than anyone else.

All that said, I don't really object to Akamai's nameserver having
been publicly named as a problem for qname minimisation.  Identifying
potential problems is obviously a crucial part of protocol
development.  Just remember, though, on n'attrape pas les mouches avec
du vinaigre.  We are all colleagues here, working to the same end -- a
better Internet. 

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

Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-edns-client-subnet-06: (with COMMENT)

[Dave Lawrence]

Ben Campbell writes:
> I agree with Stephen's DISCUSS, and his comment about mentioning that
> this documents rather than recommends existing behavior in the abstract.
> (Or at least closer to the beginning of the introduction.)

Do the changes that I indicated in my response to Stephen work for
you?

Thank you all for the reviews.

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

Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-edns-client-subnet-06: (with COMMENT)

[Dave Lawrence]

Alissa Cooper writes:
> I support Stephen's DISCUSS point. My assumption in reading the
> recommendation is that all recursive resolvers are recommended to disable
> ECS by default.

Please confirm that this new paragraph at the end of the privacy
section, written in response to Stephen's message, addresses your
concerns as well:

   We recommend that the feature be turned off by default in all
   nameserver software, and that operators only enable it explicitly
   in those circumstances where it provides a clear benefit for their
   clients.  We also encourage the deployment of means to allow users
   to make use of the opt-out provided.  Finally, we recommend that
   others avoid techniques that may introduce additional metadata in
   future work, as it may damage user trust.

> = Section 1 =
> "The
>motivation for a user to configure such a Centralized Resolver varies
>but is usually because of some enhanced experience, such as greater
>cache security or applying policies regarding where users may
>connect."
> 
> Assuming by "user" you mean end user of the DNS, I think this would make
> more sense if it said "user or ISP" or something like that. I assume it's
> much more common for ISPs to explicitly choose to use centralized
> resolvers than for end users to do so.

I think you're probably right, even taking into consideration that the
original motivation for this came from OpenDNS and Google running
resolvers that users had to affirmatively select.  Either way, I've
changed the text from:

   motivation for a user to configure such a Centralized Resolver varies

to

   motivation for having such Centralized Resolvers varies 

Does this work?

> = Section 2 =
> Given that you reference specific implementations in various places in
> the document, would be interesting to note any specific implementations
> that surface the opt-out choice to users.

An excellent point.  As far as I know, getdns is the only stub
resolver currently offering it, thanks to Daniel Kahn Gillmor at the
last Hackathon.  Is it acceptable to say "regrettably" about something
in an RFC?  I could put this in as the final paragraph of the Privacy
Note:

   Regrettably, support for the opt-out provisions of this specification 
   are currently limited.  Only one stub resolver, getdns, is known to
   be able to originate queries with anonymity requested, and as yet
   no applications are known to be able to indicate that user
   preference to the stub resolver.

> = Section 5 =
> 
> s/client location/client network location/

Done.

> = Section 7.2.1 =
> 
> "A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH
>indicates that the provided prefix length was not specific enough to
>select the most appropriate Tailored Response.  Future queries for
>the name within the specified network SHOULD use the longer SCOPE
>PREFIX-LENGTH."
> 
> I think it would help to expand a bit about using the exception case for
> the SHOULD here. It seems to me that this basically involves a judgment
> call by the operator of the recursive resolver between exposing a longer
> prefix or providing less useful information to an authoritative resolver
> that is indicating that it needs more information. But setting SOURCE
> PREFIX-LENGTH involved a judgment call in the first place about the
> privacy protection involved in providing a less-than-full address. So how
> is a recursive resolver supposed to decide whether to follow the
> indication from the authoritative resolver about prefix length?

Agreed that it is a bit wishy-washy.  I added this sentence to the end
of the quoted paragraph:

   Factors affecting whether the Recursive Resolver would use the
   longer length include the amount of privacy masking the operator
   wants to provide their users, and the additional resource
   implications for the cache.

Is that okay?

I'm unsure whether it warrants further expansion.  I've felt (without
hard evidence) that in practical terms it would actually be unusual
for a caching resolver to dynamically change its policy for future
requests based on longer scope lengths.  I mean sure, if the recursive
sent up a truncated source length (say,v4 /16) from their normal
policy of /24 because of a user option, then the authoritative will
come back at /24 or whatever and the recursive will subsequently use
/24 anyway because that's their default policy.  But I'm doubtful that
same resolver being told /25 in a response would then switch to using
/25 in future queries.

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

Re: [DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-edns-client-subnet-06: (with DISCUSS and COMMENT)

[Dave Lawrence]

Stephen Farrell writes:
> Section 11.3, I like that we're recommending that ECS be
> disabled by default, but want to check one thing. This says: 
> "Due to the high cache pressure introduced by ECS, the feature
> SHOULD be disabled in all default configurations."  Does that
> mean that all servers SHOULD disable this by default or does
> this only apply to some servers? If the former, it should
> probably be (re-)stated somewhere early on and more prominently
> and not only stated far down in the document like this. If the
> latter, then I think you need to be more precise and I'd like to
> know why we're not preferring the more privacy friendly option
> as our default. So I hope your answer is "yeah, all servers and
> sure we can state that earlier as well" :-)

In the draft that is pending its (presumably) final edits to make
version -07 to head to the RFC Editor, the last paragraph of the
Privacy Note (which is section 2), now says:

   We recommend that the feature be turned off by default in all
   nameserver software, and that operators only enable it explicitly
   in those circumstances where it provides a clear benefit for their
   clients.  We also encourage the deployment of means to allow users
   to make use of the opt-out provided.  Finally, we recommend that
   others avoid techniques that may introduce additional metadata in
   future work, as it may damage user trust.

Does that adequately address your concern?

> - abstract: I think it'd be good if the abstract noted that this
> was documenting a deployed option and not necessarily
> recommending this as the best thing ever. There's text in the
> write-up and intro that does that nicely that could work if
> reduced to one sentence, e.g. maybe something like: "This
> documents an EDNS0 option that is in active use on the Internet
> today that is intended to be revised in the near future to
> improve it's security and privacy features."  

How is this for the new abstract?

This document describes an EDNS0 extension that is in active use
to carry information about the network that originated a DNS
query, and the network for which the subsequent response can be
cached. Since it has some known operational and privacy
shortcomings, a revision will be worked through the IETF for
improvement.

> - 7.2.2 says "Because a client that did not use an ECS option
> might not be able to understand it, the server MUST NOT provide
> one in its response." That seems like a bit of a pity - one
> comment I was going to make was that it might be good to include
> this (or something) in a response so that a client that didn't
> ask for ECS could be informed that some DNS server is doing ECS.
> Would that actually break things? 

I don't think anyone has real experimental evidence on this.  We do
see a lot of variation in the way that various DNS servers handle EDNS
in general, but I believe pretty much all of it has been with regard
to how servers handle EDNS anomalies in requests, and not with its
unexpected presence in responses.

Given the lack of experience in this area I'd be reluctant to include
anything about it in this document, but will certainly consider
looking into it more for the revision.

> - section 10 has RFC1918 as a SHOULD but doesn't refer to e.g.
> RFC6598 at all.  RFC6890 has a MAY associated with it, but does
> refer to 6598. And what about stuff like RFC7534, which isn't
> mentioned? Is that all correct and up to date? 

I believe it is good as-is; we actually have known operational use
cases of allowing things like CGNAT through because a co-operating
resolver and authority have shared information about what the network
looks like.  This is covered a little in the section on NAT
Considerations.  If there's still something problematic I'd be happy
to address it.

> - 11.1, 4th para: "Users" isn't really right. People don't know
> about any of this stuff really. "Clients" would be more accurate

Rephrased from:

   Users who wish their full IP address to be hidden can include an
   ECS option specifying the wildcard address (i.e.  SOURCE
   PREFIX-LENGTH of 0).

to:

   Users who wish their full IP address to be hidden need to configure
   their client software, if possible, to include an ECS option
   specifying the wildcard address (i.e.  SOURCE PREFIX-LENGTH of 0).

Good? 

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

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

[Dave Lawrence]

A couple of quick observations:

* The draft says that the answer in a signed zone MAY be unsigned.
  Since this will ultimately cause a SERVFAIL for validating
  resolvers, it is not really acceptable.

* The draft does not describe at all what the proper behaviour is for
  an owner name that has a CNAME record.  Since CNAMEs require special
  handling, this should be addressed.  Personally I think the CNAME
  should be returned in this case.

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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

[Dave Lawrence]

Thank you, Jinmei, for your thoughtful feedback.

Jinmei writes:
> It would be nicer if it can be clarified before advancing
> it: are we expecting newer implementations are developed based on this
> specification, or is this document literally for describing the
> current practice for the record (and newer implementations should
> rather wait for more complete specification in the assumed revised
> publication)?  This point wasn't clear to me, and I hope it's more
> clearly stated in the final version of the document.

While I appreciate your overall point, I think in practical terms we
can't really expect the parenthetical above, that "newer
implementations should rather wait".  Even if I had that draft pushed
out right this very minute, realistically it'll be a year for it to
get through IETF review, and additionally have somewhat less incentive
for rapid adoption than the original draft did.

Anyone that wants to interoperate with the companies currently using
ECS in any "Internet-speed" timeframe is going to have to support this
method, which even with the minor flaws that has, is still basically
pretty good for addressing the original goals that motivated it.

That said, I can add this remark to the end of the introduction:

"A revised proposal to improve upon the minor flaws in this protocol
will be forthcoming to the IETF."

Is that reasonable enough to address your concern?

> Some more specific comments on the draft text follow, most of which I
> think are minor and non-blocking:

Thank you, I have incorporated most of these into our github version,
to be -05.

> - Section 4: the term "Forwarder" is used without a definition.  I
>   think it's often confusing (different people tend to use it for
>   different meanings), so it would be better to give its definition
>   for the purpose of this document.

This was one of the most interesting comments to me, because it
actually revealed a source of terminology confusion in the DNS for
which the document was at odds with other RFC usage.  The confusion is
not unlike that of "CNAME", as far as source and target are concerned.

A Forwarder in the RFC sense has been the target of forwarded queries,
while elsewhere (such as Microsoft Technet notes, and this document)
expect it to be a server that does the forwarding to another recursive.
(I suppose that would make the target a "Forwardee".)

I have added this definition, and changed occurrences of "Forwarder"
to "Forwarding Resolver":

   Forwarding Resolver  A nameserver that does not do iterative
  resolution itself, but instead passes that responsibility to
  another Recursive Resolver, called a "Forwarder" in [RFC2308]
  section 1.

>o  SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost
>   significant bits of ADDRESS to be used for the lookup.
> 
>   I think it'll be more accurate if it says: "representing the number
>   of leftmost significant bits".  Same for SCOPE PREFIX-LENGTH.

Added "number of" to both.

> - Section 7.1.1
> 
>An ECS-aware resolver MUST retry the query without ECS to distinguish
>the response from a lame delegation, which is the common convention
>for a REFUSED status.
> 
>   Is this true?  To me it's a rather unusual choice to indicate a lame
>   delegation.  For example, if I remember it correctly ISC BIND 9
>   returns SERVFAIL if all supposed-to-be-authoritative servers are
>   lame.

Right, a recursive would return servfail for its client, but it is
true for authorities, including BIND 9.9.7-P2 running at ISC:

$ dig whatever.whatever @ord.sns-pb.isc.org | grep status
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 12817

> - Section 7.2.1
> 
>If the Authoritative Nameserver operator configures a more specific
>(longer prefix length) Tailored Response within a configured less
>specific (shorter prefix length) Tailored Response, then
>implementations can either:
> 
>   Just checking: is this an attempt to address the suboptimal scenario
>   I raised in my review of a previous version of draft?

I'd have to dig up the history, honestly.

> - Section 7.4, first paragraph:
> 
>The prohibition against tying ECS data to records from the Authority
>and Additional section left an unfortunate ambiguity in the original
>specification, primarily with regard to negative answers.  The
>expectation of the original authors was that ECS would only really be
>used for address records, the use case that was driving the
>definition of the protocol.
> 
>   The second sentence sounds a bit awkward to me, since the issue of
>   negative answers should basically be irrelevant to whether the query
>   is for "address records".  Perhaps it's intended to explain the
>   background on the issue with delegation cases?

It was trying to describe that the main thing that was trying to be
accomplished originally was just to enable positive tailored responses
to address queries.  I've changed the second sentence to 

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

[Dave Lawrence]

David Dagon writes:
> I have some concerns, which I describe below. [...]

David,

Thank you very much for your thoughtful comments.  Broadly speaking, I
very much agree with the bulk of them.  Yet my current reaction is not
to make any more alterations to the existing document.  It describes
the deployed protocol as-is, and your comments are appropriate for
consideration for the revised protocol, where I can assure you they
will definitely be integrated.

Is there something specific about documenting (yet not endorsing) the
in-use protocol that you think is important to get into the document
before publication?






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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

[Dave Lawrence]

John Dickinson writes:
> I suggest that the IESG Note be moved to the main text and not be
> removed prior to publication.

I agree, and am making some edits today for review by the co-authors.

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