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

[Matthew Pounsett]

On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:

>
>
> On 3/28/23 03:14, Shumon Huque wrote:
> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni  > wrote:
> >
> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> > Can we at least state that domains with cyclic dependencies are a bad
> > idea, and may not be supported by all resolvers.  In other words,
> that
> > the domain owner can't **rely** on the sibling glue recommended to be
> > sent in this draft to save the day.
> >
> > My strong preference is still to delete all reference in the draft to
> > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> > sibling glue primarily as a performance optimisation, and secondarily
> > as a last resort when the nameserver IP addresses are wrong or gone
> > from the authoritative zone (another bad practice).
> >
> >
> > Viktor - I've so far not seen many other people speak up in support of
> your
> > position. I suspect this is because this draft was discussed to death
> many
> > months ago during long discussion threads on the list, and there is
> likely
> > already rough consensus for the current content. Personally, I would be
> ok
> > with adding a statement that configurations involving cyclic dependencies
> > are not recommended, but others will likely have to also speak up in
> support
> > of this too.
>
> I support adding such a statement about cyclic dependencies.
>

As do I.


>
> In addition, I would support saying that data suggests that, while
> (non-cyclic) glue records may have a benefit in certain cases, they
> frequently are a source of harm (time-outs), and the trade-off remains
> unclear.
>

I would support this as well.

In my anecdotal experience as an operator, I routinely encounter mismatches
in sibling glue and child zone NS sets that appear to be due to the glue
being forgotten.  My assumption is that, because it's not necessary to
operate, when operators fail to update it they don't receive any kind of
signal that something is wrong.

Viktor's numbers are pretty clear data, though, so nobody should need my
anecdotes to be convinced.  While sibling glue may be a useful optimisation
in some cases, given how poorly maintained it is it seems to cause more
problems than it solves.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Fwd: DNSSEC algorithm used on ietf.org

[Matthew Pounsett]

On Wed, Mar 23, 2022 at 3:20 PM Petr Menšík  wrote:
>
> Yes, it says so. It also says SHA-1 is not recommended for new
> signatures and ietf.org signature was made at 20220318000627.

It's more accurate to say that it's not recommended for new
deployments.  Operators are encouraged to migrate to more secure
algorithms, but given an existing deployment there's no MUST
associated with that migration, yet.

> Is there
> reason why DNS is so better protected than TLS certificates? Is its
> shorter message length a good protection? I don't understand the
> difference between
>

It's to do with the expected lifetime of the signatures, and the fact
that we're dealing with signatures, not encryption.  There is no need
to have years of protection from a single key or signature, as there
is with encryption and privacy, as is intended for TLS.

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

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

[Matthew Pounsett]

On Mon, 27 Jan 2020 at 10:09, Hugo Salgado  wrote:
>
> Dear DNSOPers, as an operator I tend to have this need to couple
> an answer for a query to an auth server, with the actual "SOA zone
> version" used. So I think it'll be valuable to have an EDNS option
> for it.

I also missed this the first time around.  Mauricio brought it up
during the OARC workshop last night; I think it's a very good idea,
and the WG should adopt it.  There are many occasions in the past
where this would have been helpful in debugging, and I'm sure there
will be many more in the future.

I haven't read this in detail yet, but I will happily provide reviews
if the WG adopts it.

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

Re: [DNSOP] [Ext] Questions on draft-ietf-dnsop-private-use-tld-01.txt

[Matthew Pounsett]

On Mon, 19 Apr 2021 at 12:34, Paul Hoffman  wrote:
> That's correct, as it would be for any private-use TLD. In fact, it's not 
> just about validating stubs: an organization wanting to use a private-use TLD 
> cannot have validating stub resolvers or validating recursive resolvers 
> anywhere in the organization.

* Unless they configure the appropriate exceptions into those resolvers/stubs.
(Spoken as someone who has set up validating resolvers inside an
enterprise camping on an unregistered TLD for use in AD).

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

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-intentionally-temporary-insec-00.txt

[Matthew Pounsett]

On Thu, 25 Feb 2021 at 14:14, Ben Schwartz  wrote:

> The most interesting informational element, in my view, would be guidance
> on how to detect buggy implementations that will create this problem.  (Set
> up a test zone and a test resolver and ...?).  I think the best practice is
> probably to migrate to a better implementation before rolling the algorithm.
>

Sometimes the bug is an absent operator on the other end of the transfer.
Or an uncooperative one, which RFC 6781 doesn't really address.  I have a
zone I'm planning a move for where the only way it's going to get done,
without going through a bogus state, is by going through an insecure
state.

I'd be extremely uncomfortable labelling that kind of transfer as a best
practice, but it's operational reality that it's going to happen, and it
probably wouldn't hurt to have a document out there explaining how to do it
the best way possible.  Provided, of course, that it's heavily laden with
caveats pointing to all the more secure procedures documented that should
be ruled out first.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

[Matthew Pounsett]

On Mon, 11 May 2020 at 13:42, Tim Wicinski  wrote:

>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
> This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
>
>
I support adoption, and will review the draft.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] on private use TLDS

[Matthew Pounsett]

On Tue, 26 Nov 2019 at 12:35, Paul Hoffman  wrote:

> On Nov 26, 2019, at 9:16 AM, Matthew Pounsett  wrote:
> > I'm also persuaded by Bill's argument that the IETF has already stated
> that ISO 3166 has control over that bit of the namespace, and trying to
> take back part of it is confusing, bad form, and risky.
>
> For those who read the draft, ypu'll see that "trying to take back part of
> it" is not there. The same was made clear in the presentation to the WG.
> "If you want a private name, here's one to consider; ones like it are
> already being used as private names in dozens of other contexts" is far
> from "taking" anything.
>

It's still the IETF stating that it's safe to use for that purpose, which
is no longer the purview of the IETF having delegated that responsibility
to ISO3166.  That is taking back authority over that name.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Matthew Pounsett]

On Tue, 26 Nov 2019 at 05:19, Roy Arends  wrote:

> “ZZ” was used in my presentation as an example. Since this bikeshedding is
> siphoning attention from the important part of the discussion, I’ll try to
> re-focus on the question here:
>
> "Is it safe to use ISO3166-1 Alpha-2 code elements from the User Assigned
> range as top level domains for my own private use?"
>

Thanks for the context, Roy.  Speaking as someone who was not at the IETF
meeting this week, I found the earlier thread confusing.  But, it looks
like the assumed context of bringing up "what can we use this for" as "can
we assign this string in an RFC?" was correct.

It seems like reassignment of anything in the User Assigned range is
unlikely, however that is the purview of the iSO 3166 maintenance agency,
and not the IETF.  However unlikely it is, we cannot be absolutely certain
they will never reassign those, and so we should not include them in any
standard (note the lower-case) published by the IETF.  Even if the IETF is
just cut & pasting their current advice, I think it's unwise.

I'm also persuaded by Bill's argument that the IETF has already stated that
ISO 3166 has control over that bit of the namespace, and trying to take
back part of it is confusing, bad form, and risky.

Even though they're not specifically proposed, only mentioned in passing,
I'd also like to point out that the referenced potential uses of things
like XH instead of home.arpa. is even more risky, because that fixes that
string for a specific use, even if it's private.  Using XH as an example,
if that had been chosen it would run the risk of colliding with some
legitimate use of XH already being used by a User.. if that user then also
needed to interoperate with Homenet technologies they'd be hosed.

I think, instead of an RFC, what you really want is a Best Current
Practices document, outside of the IETF, that is simply a redirect to the
current ISO 3166 document.  Instead of DNSOP, I'd suggest you have a chat
with one or more  of the BCOP efforts at the NOGs.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On .ZZ

[Matthew Pounsett]

On Fri, 22 Nov 2019 at 09:05, Roy Arends  wrote:

>
>
> >
> > I read that to mean they are reserved for private use, and as mentioned
> above, any centralized/standardized use is going to conflict with that.
>
> No.
>
> No one is suggesting centralised use! The opposite. You can use it locally
> because there is no centralised use.
>

Standardized use isn't the same as globally reachable.  If you say "this
thing can be used for purpose X in any network" what happens when it's
already in use for purpose Y in someone's network, and they need X to work?


>
> Using your analogy, there should not be an RFC1918 because it
> “standardizes” that 10/0 (etc) can be used for private internets.
>
> > I'm surprised this thread has such legs.  I would have thought this
> would wind up when home. and home.arpa were mentioned way up thread.
>
> I’m surprised that this thread contains so much mis-information.
>

It would probably help if the thread had started with the intended use.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On .ZZ

[Matthew Pounsett]

On Fri, 22 Nov 2019 at 05:16, Dr Eberhard W Lisse  wrote:

>
> If users need code elements to represent country names not included
> in this part of ISO 3166, the series of letters AA, QM to QZ, XA to
> XZ, and ZZ [...] are available.
>
> I read that to mean that a .ZZ (or rather any of the 42 possibles) would
> be safe to use in our context.
>

I read that to mean they are reserved for private use, and as mentioned
above, any centralized/standardized use is going to conflict with that.
 This is a bit like IANA trying to assign a bit of RFC1918 space to
something specific and global.

I'm surprised this thread has such legs.  I would have thought this would
wind up when home. and home.arpa were mentioned way up thread.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-7706bis

[Matthew Pounsett]

On Thu, 31 Oct 2019 at 11:48, Tim Wicinski  wrote:

> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak
> out with your reasons.
>

Just a nit:
In Appendix B4, is the extra indenting of "fallback-enabled" intentional?
I'm not as familiar with Unbound syntax, but that looks odd to me.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt

[Matthew Pounsett]

On Wed, 6 Nov 2019 at 09:38, Ray Bellis  wrote:

>
>
> On 06/11/2019 13:42, Matthew Pounsett wrote:
> > I still have a few comments.  There were a few comments from my review
> > of -13 that weren't responded to in email, and haven't been updated in
> > the text, so I'm repeating them here.
>
> Hi Matt,
>
> We sought advice from one of the Chairs as to whether in his reading
> such a significant restructuring of the document was warranted when only
> one participant was calling for it.
>

I'm not actually calling for a restructuring of the document.  I'm calling
for the structure of the document to be followed.  Cleaning up section 3 by
moving its tests to section 8 and clearly describing non-response problems
instead is just following the existing structure of the document.

I did leave it open for you to restructure the document if you wish, to
actually combine sections 3 and 8.

Perhaps this response will encourage others to speak up about whether they
think either of those things are important changes.  It's possible people
saw my review of -13 and didn't feel the need to comment since someone else
already had.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt

[Matthew Pounsett]

I still have a few comments.  There were a few comments from my review of
-13 that weren't responded to in email, and haven't been updated in the
text, so I'm repeating them here.

As mentioned in my last review, Section 3 seems very confused about what
it's trying to accomplish.  Some subsections list only correct behaviour,
some only list incorrect behaviour, while other sections list only a test
for correct behaviour without actually describing either the correct
behaviour or the commonly observed misbehaviour.  These latter sections are
the most confusing, because tests are expected to be in section 8, based on
the current structure of the document.

If the authors wish to keep the description of problem responses separate
from the description of tests, then that should be done throughout the
document, and not just for some tests. If the authors wish to mix testing
and problem description, then that should be done consistently, and section
8 should be removed entirely.  I said in my last review that this isn't an
absolute requirement that should block publication, but while the
information is all there to be found I still think it's better writing (and
therefore an easier document to parse and act on) if sections 3 and 8 are
consistent in their content.

Presuming that the authors wish to keep problem description and test
description separate, then section 3 should be consistent about describing
at least good behaviour for each type of query and leaving off tests.  Bad
behaviour can be assumed to be non-response, based on the subject of the
document, but incidental mention of other common misbehaviours or common
reasons for misconfiguration wouldn't be out of place, I think.

I've done a section-by-section review of 3.x this time, using the
assumption that sections 3 and 8 will remain separate.  For some sections
I'm suggesting specific text to make clear what I think needs to change,
but I think all of those subsections of 3 mentioned below need rewriting.
Without a clear indication from the authors about which way they want the
structure of the document to go, it's hard to commit the time to suggest
rewrites for the entire section.

It would be good to hear back from the authors about whether they think
these issues are non-problems, and why, or whether they intend to address
them in a later version.

3.1.1 - A test description leads ahead of correct behaviour.  This section
doesn't discuss non-response at all.
Suggested text:
If a zone is delegated to a server, that server should respond to an SOA
query for that zone with an SOA record.  Failing to respond at all is
always incorrect, regardless of the configuration of the server.
Responding with anything other than an SOA record in the Answer section
indicates a bad delegation.

3.1.2 - A test description leads ahead of describing incorrect behaviour.
Correct behaviour is never described.  The test should be removed to
section 8, and this should just describe failing to respond to unsupported
QTypes, and what a correct response should look like.  I'm supplying two
suggested text blocks, the latter of which incorporates Viktor Dukhovni's
suggestion about NOTIMP.
Suggested text:
Some servers fail to respond to unknown or unsupported types.  If a server
receives a query for a type that it doesn't recognize, or doesn't
implement, it is expected to return the appropriate response as if it did
recognize the type but did not have any data for that type: either NOERROR,
or NXDOMAIN.
or
Some servers fail to respond to unknown or unsupported types, while others
may respond with an incorrect rcode of NOTIMP.  If a server receives a
query for a type that it doesn't recognize, or doesn't implement, it is
expected to return the appropriate response as if it did recognize the type
but did not have any data for that type: either NOERROR, or NXDOMAIN.

3.1.3 - Good behaviour isn't described.

3.1.5 - The test in the second paragraph should be removed to section 8

3.2.1 - This section leads with a test that should be removed to section
8.  The final paragraph is useful, but expected good behaviour needs to
replace the first two.

3.2.2 - The last sentence of the second paragraph is potentially confusing,
I think.  Is it talking about misbehaviour of authoritative servers, or
misinterpretation by recursive servers of a bad response from authoritative
servers?  I'm pretty sure it's the latter... so, text:
Such answers will [may?] be misinterpreted by the client, and get discarded
or treated as new requests.

3.2.3 - This section does not suffer from the problem described above.
However, I think it could use some re-ordering to make it even clearer what
the correct behaviour is:
Some servers fail to respond to EDNS queries with ENDS options set.  The
original EDNS specification left this behaviour undefined [RFC2671], but
the correct behaviour was clarified in [RFC6891].  Unknown EDNS options are
supposed to be ignored by the server.

3.2.5, second paragraph - It's 

Re: [DNSOP] Confirmation of RFC Ed edits on RFC 8618 (draft-ietf-dnsop-dns-capture-format)

[Matthew Pounsett]

On Wed, 7 Aug 2019 at 11:16, Warren Kumari  wrote:

> I'm planning on approving on Monday Aug 12th if I don't hear otherwise.
> Thanks to the RFC Editor and authors for their detail and diligence
> getting the document polished.
>

Where would one find the diffs for these changes?  The datatracker doesn't
show any updates to the document since the beginning of June.  Is there
another tracker somewhere for the RFC Editor Queue?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] proposal: Covert in-band zone data

[Matthew Pounsett]

On Mon, 22 Jul 2019 at 14:00, Dan Mahoney  wrote:

> On NOTE:
>
> Moving to the DNS-vendor standard answers of "just use DDNS" or "put it in
> an IPAM" add additional complexity, and additional attack surfaces.  DNS
> servers have a tenuous relationship with database backends, and I spend
> enough time patching my DNS servers without having to patch an IPAM.
>

"Just use DDNS" is actually harmful advice in many situations, for exactly
the reasons you've raised.  Maintaining versioning and "blame" (who made
what change when) is overly complex when trying to use DDNS-based zone
maintenance.  Not to mention I can put together a fairly decent zone change
management process using version control and zone files with off-the-shelf
software that any small enterprise can make use of ... there just aren't
any good OSS zone editors based on DDNS that I'm aware of, and small
enterprises can't afford to do a ton of in-house software development to
make something purpose built.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Review of draft-ietf-dnsop-no-response-issue-13

[Matthew Pounsett]

I promised a new review of this document a long time ago.  Apologies for
taking so long to get around to it.

This is a huge improvement over previous versions.  I'd like to thank the
authors for such an extensive cleanup.  I sill have a few style suggestions
(and grammar nits), which I think would make it a better document, but
nothing that should actually block it from proceeding.

My only real structural suggestion is that I still find the style of the
subsections of section 3 to be odd reading.  Some sections only describe a
correct behaviour (3.1.3.1), some only describe a common incorrect
behaviour (3.1.3), others only describe a test for detecting whether a
server behaves correctly or not (3.1.1). Most subsections of 3.x are
combinations of two or more of these in apparently random order; some lead
with a test, some lead with an incorrect behaviour, some lead with a
correct behaviour.   Having a more consistent structure to these sections
would make the document easier to read and act on.

I think tests should be left out of 3.x entirely, and moved to section 8 if
they aren't already there.  If the authors want to point out tests in this
section, a pointer to the relevant subsection of 8.x would be more
appropriate.

The rest of my comments are smaller style or grammar nits:

Section 3 title:  "Common queries kinds"
I raised this issue in a previous version; this does not seem to be correct
English.  Do the authors mean "Common kinds of queries"?


Section 7, paragraph 2:
   For unimplemented opcodes NOTIMP is the expected response code.  For
   example, a new opcode could change the message format by extending
   the header or changing the structure of the records etc.

This is not, strictly speaking, an example of what's being talked about in
the previous sentence.  Suggested text:

   Newly implemented opcodes may change the message format by extending the
   header, changing the structure of the records, etc.  Servers are not
   expected to be able to parse these, and should respond with a response
code
   of NOTIMP when they encounter a query with an unknown opcode, rather than
   dropping the message.

Section 8:

Most of the second paragraphs of the subsections of 8 are written with the
general structure of:

We expect A with B and C and D.

I find this to be awkward list construction.  I think it would be more
useful to structure these as:

We expect A, B, C, and D.

For example, subsection 8.1.2:

   We expect no records to be returned in the answer section with the
   rcode set to NOERROR and the AA and QR bits to be set in the
   response; RA may also be set [RFC1034].  We do not expect an OPT
   record to be returned [RFC6891].

This could be:

   We expect no records to be returned in the answer section, the rcode to
be
   set to NOERROR, and the AA or QR bits to be set in the header;  RA may
also
   be set [RFC1034]. We do not expect an OPT record to be returned
[RFC6891].

I'm happy to provide suggested text for all of these if that's useful to
the authors.


8.1.3.1, first paragraph.  Too many "and"s, not enough commas. :)
Suggested text:
   Ask for the SOA record of the configured zone.  This query is made
   with only the CD DNS flag bit set, all other DNS bits clear, and
   without EDNS.

8.2.3, first paragraph:
   Any unassigned EDNS option code could have be choose for this test.
   Any unassigned EDNS option code could have been choosen for this test.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ANAME loop detection

[Matthew Pounsett]

On Thu, 4 Jul 2019 at 10:54, Matthijs Mekking 
wrote:

> Matthew,
>
> > I would say they should rely on that.  Why shouldn't they?  Isn't our
> > goal to get downstream servers to adopt the extension and do their own
> > lookup?  The server-side lookups and sibling records are bolt-ons to
> > handle the adoption period.  Remember, this record is geared toward
> > customers of CDNs being able to do get similar behaviour to:
> > www.example.com . IN CNAME webfarm.cdn.net
> > .
> > at the apex of example.com .  That was the original
> > problem we're trying to solve.  I read your statement above about "the
> > service they provide their customers" being about the CDN resolving
> > webfarm.cdn.net , which most CDNs can already do
> > within their own infrastructure.
>
> I am talking about DNS providers that perform CNAME at the Apex like
> features: a customer goes to them and opts in to this feature. Such a
> provider wants to make sure that it is providing the behavior the
> customer expects and thus wants to make sure it hands out appropriate
> addresses.
>

And "CNAME at the Apex like feeatures" is to hand out a CNAME and let the
downstream server process that.  It may include additional information from
other zones it is authoritative for, but it doesn't do side-lookups.  I
think that's the behaviour we should be aiming for, and to do that some
sort of "I understand ANAME" signal would allow the authoritative server to
behave more like CNAME.


>
> Also what is wrong with an authoritative server already giving out more
> optimal answers than just the ANAME and sibling address records?
>

Nothing, as long as it's not going to increase the time it takes to respond
to the query.

But, you didn't respond to my question.  Let me rephrase it a bit:  If the
authoritative server knows the client understands ANAME, why would the
authoritative server not assume that any additional data it supplies will
be thrown away?I suggest that it would be wise for an authoritative
server to assume that a client that understands ANAME will resolve its own
ANAME and ignore any other data it gets.


>
> > Option #2 gets similar behaviour but at the cost of additional lookups.
> > #3 and #4 don't work well in the presence of server farms.
>
> If addresses are in the response to the ANAME request there is no
> difference in number of lookups between 2 and 3 I think.
>

Did you mean "lookups between 1 and 2"?I didn't say anything about the
number of lookups required for 3.  I think 3 and 4 are poor choices because
they won't behave well with most server farms.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ANAME loop detection

[Matthew Pounsett]

On Thu, 4 Jul 2019 at 05:54, Matthijs Mekking 
wrote:

> >
> > 1. EDNS "do not follow ANAME" option: The requester would indicate
> > that it is capable of following ANAME and that the server receiving
> > the query should not include the ANAME sibling address records. The
> > loop detection would then work exactly the same ways as with CNAMEs.
>
> This would be an easy addition I think, however I thought the "do not
> follow ANAME" option actually meant "really don't do a target lookup I
> can do it myself".  The authoritative server can still send the sibling
> address records that are placed in the zone, they can be used if the
> requester fails to perform the ANAME target lookup (for example due to a
> network error or outage).
>
> Furthermore, a service provide receiving such a request might want to
> ignore it if it feels strongly it should hand out more appropriate
> addresses than the sibling records (basically because that is the
> service they provide their customers, will they rely on an EDNS option
> from the requester saying "no really I can do this"?).
>

I would say they should rely on that.  Why shouldn't they?  Isn't our goal
to get downstream servers to adopt the extension and do their own lookup?
The server-side lookups and sibling records are bolt-ons to handle the
adoption period.  Remember, this record is geared toward customers of CDNs
being able to do get similar behaviour to:
www.example.com. IN CNAME webfarm.cdn.net.
at the apex of example.com.  That was the original problem we're trying to
solve.  I read your statement above about "the service they provide their
customers" being about the CDN resolving webfarm.cdn.net, which most CDNs
can already do within their own infrastructure.

Sending out the sibling records in the presence of this EDNS option might
make sense as a backup, since that is low effort on the part of the
authoritative, but a declaration by the querying server that it understands
ANAME and is prepared to do its own lookups should be trusted by the
authoritative server, and it should not to recursive lookups.  To take that
further, why would the authoritative server believe that the results of any
lookups it does would not be thrown away?

This EDNS option should also be useful to recursive servers that understand
ANAME, and are planning to do their own ANAME resolution.  They can get
their answer from the authoritative server much faster this way.

This is also a way to measure adoption.  As the ratio of "EDNS do not
follow ANAME" queries to total ANAME queries approaches 1.0, we know that
adoption has been successful.  Maybe we could even begin to deprecate
authoritative resolution (of ANAMEs) at that point, and begin to get back
to something that looks more like plain CNAME.

I would suggest that better EDNS semantics would be just "I
understand/support ANAME".   That gets the desired information across
without the sense of sending a command to the upstream server.

Option #2 gets similar behaviour but at the cost of additional lookups.  #3
and #4 don't work well in the presence of server farms.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Verifying TLD operator authorisation

[Matthew Pounsett]

On Sat, 15 Jun 2019 at 19:36, Nick Johnson  wrote:

>  On Sat, Jun 15, 2019 at 2:21 AM Stephane Bortzmeyer 
> wrote:
>
>> On Fri, Jun 14, 2019 at 02:38:11PM +1200,
>>  Nick Johnson  wrote
>>  a message of 173 lines which said:
>>
>> > Indeed - it's my understanding that ICANN forbids publishing anything to
>> > the root zone other than necessary records such as SOA, NS and DNSKEY.
>>
>> You mean the TLD zone?
>
>
> Sorry, yes I did.
>
>
The set of allowed RRTYPEs in a gTLD zone can (and does) change, given a
reasonable justification, and enough interest and pressure from the
registries.  For example, the last revision of the Registry Services
contract that ICANN put out[0] added a record for zone versioning
independent of the SOA record.

You can get a new RRTYPE reserved for your purposes quite easily[1].  With
that, you could run a trial with some early-adopting ccTLDs (not
constrained by ICANN's Registry Services contract) to demonstrate the
utility of your scheme.  If it's attractive enough to warrant the internal
process and development costs to deploy, and the ICANN lobbying efforts,
then the gTLD operators could have it added to the contract.

Whatever your deployment method, you will need to demonstrate some benefit
to the registries if you want them to adopt your scheme.  Making changes to
their process isn't cheap, and there is no such thing as a one-off cost;
everything added to their operation needs to be maintained and monitored,
which incurs an ongoing cost.

[0]: Exhibit A, §1.1 <
https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.pdf
>
[1]: 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

[Matthew Pounsett]

On Thu, 11 Apr 2019 at 20:02, Richard Gibson
 wrote:
>
> The first problem is for the owner of the ANAME-containing zone, for whom the 
> upstream misconfiguration will result in downtime and be extended by caching 
> to the MINIMUM value from their SOA, which in many cases will be one to three 
> orders of magnitude greater than the TTL of the ANAME itself.

[snip]

> But this suffers from both of the problems I have been complaining about—the 
> resolver does not necessarily have the zone SOA, possibility necessitating an 
> inline lookup, and per RFC 2308 the negative response will be cached 
> according to values from the SOA that are unrelated to and far exceed the TTL 
> of the ANAME.

Ah, I see the confusion.  You're using definitive statements such as
"will" when what you actually mean is "may."   There's no specific
mechanism that causes the client to cache the negative response "for
one to three orders of magnitude greater than the TTL of the ANAME."
And, the TTL of the SOA doesn't necessarily "far exceed" the TTL of
the ANAME.  You're just presupposing that will be a common
configuration?

I think we're still talking about misconfigurations here, and
designing a protocol around people who misconfigure their DNS at the
expense of people who configure it properly seems like a bad path to
take.

> Both of these problems can be addressed by allowing/recommending/requiring 
> ANAME-aware servers to preserve ANAME siblings when resolution of ANAME 
> targets results in NXDOMAIN or NODATA responses, rather than replacing them 
> with an empty RRSet... which, to be honest, seems to be always-undesirable 
> behavior anyway—if anyone can think of a scenario where it would be 
> beneficial to dynamically remove ANAME siblings, please share it.

Yes, I can think of a case where it would be beneficial to remove
ANAME siblings: when the target of the ANAME is removed from the DNS.

> In such a configuration, the owner of the ANAME will be able to see that 
> clients are using its static sibling records rather than its target (and 
> therefore that they are getting no benefit from the ANAME), and can react 
> accordingly. If your concern is excess queries for the ANAME target, then 
> this seems no different from e.g. CNAME—the owner of the target can issue 
> long-lived negative responses while performing whatever other exploration 
> and/or mitigation they deem fit.

If the target of the ANAME disappears, the owner of the ANAME will
similarly be able to recognize the problem and deal with it.  If the
administrator of the name owning the ANAME is concerned about downtime
due to misconfigurations by the target, then that administrator can
either select a different target (presumably by selecting a different
service provider) or set their TTLs appropriately to not be subject to
the potential issue you identified above.

However, if the spec requires preserving the target in the DNS despite
the administrator of the target zone removing it, then that is a path
for abuse by the administrator of the zone containing the ANAME, and
the owner of the target will have no recourse.  This is what I meant
by my reference to serve-stale.

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

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

[Matthew Pounsett]

On Wed, 10 Apr 2019 at 16:43, Richard Gibson
 wrote:
>
>
> The first problem is for the owner of the ANAME-containing zone, for whom the 
> upstream misconfiguration will result in downtime and be extended by caching 
> to the MINIMUM value from their SOA, which in many cases will be one to three 
> orders of magnitude greater than the TTL of the ANAME itself.

I think I'm missing something here.  If, for example, the TTL of the
ANAME is 1 hour, what mechanism results in caching holding onto a
negative answer for a broken target name for a minimum of 10 hours,
and to 40 days?

>
> Both of these problems can be addressed by allowing/recommending/requiring 
> ANAME-aware servers to preserve ANAME siblings when resolution of ANAME 
> targets results in NXDOMAIN or NODATA responses, rather than replacing them 
> with an empty RRSet... which, to be honest, seems to be always-undesirable 
> behavior anyway—if anyone can think of a scenario where it would be 
> beneficial to dynamically remove ANAME siblings, please share it.

I feel like this is creating an even bigger potential problem.  What
happens when the owner of the ANAME target legitimately wants that
name to go away, but some other zone owner is leaving an ANAME in
place pointing to that now-nonexistent name?  Continuing to serve the
sibling records indefinitely seems like serve-stale gone horribly
wrong.

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

Re: [DNSOP] Semantics of draft-brotman-rdbd

[Matthew Pounsett]

On Fri, 29 Mar 2019 at 10:31, Joe Abley  wrote:

> Hi Matt!
>
> (Replying on dnsop but noting that dbound was the suggested venue)
>

My bad.  Obviously I missed that request. I'll move there.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Semantics of draft-brotman-rdbd

[Matthew Pounsett]

I think the weak semantic definition of this record makes it either not
useful, or actively dangerous, depending on how the consumer of a record
chooses to interpret it.

As I mentioned at the mic in dnsop, it looks to me like the core motivation
of all of the described use cases are actually based around sending signals
to anti-abuse researchers.  If that is the case, then I think that should
be clear.  If those other use cases have other potential motivations for
deploying the record, then those should be more clearly articulated.

With the weak semantics I have concerns about how absent or unidirectional
mappings might be interpreted by researchers.  Where ignorance of the
existence of the record might injure the operations of a domain, or where
an attacker might gain advantage by associating themselves with a visually
similar domain with which they are not actually associated.

I think this needs to be thought about in a lot more detail, and at least
have the risks fleshed out in the draft.  Depending on the outcome of those
discussions I may prefer to see stronger semantics before supporting the
draft, or to see it abandoned entirely.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt

[Matthew Pounsett]

On Wed, 13 Feb 2019 at 22:56, Wessels, Duane  wrote:

> The only change to this document since -05 is to note that ZONEMD has been
> allocated RR type code 63 by IANA following an expert review back in
> December.
>

I haven't reviewed this for a couple of revisions, so some notes here that
don't apply to the new codepoint. :) . I've tried doing some searches of
the discussion history to make sure I'm not raising points already
addressed, but my apologies if I've missed something.

Section 2 discussion:  I was initially ambivalent about whether multiple
ZONEMD records should be allowed with different digest types.  Having gone
back and re-read some of the discussion, I'm persuaded that it would be
beneficial to allow multiple digest types to be used on the same zone
instance.  I think we'd want to have a bunch of discussion about the
details in order to keep code complexity under control, though.

Section 3.2. discussion:  Unless there's a potential benefit to non-apex
ZONEMD records that I'm not seeing, I think it makes sense to forbid them.
Was there a particular thing that could be enabled by that, which prompted
the suggestion?

In 3.4.1 would it make sense to include a sentence explaining the catch-22
that would result if the RRSIG covering the ZONEMD record were included in
the digest?

In section 4, I suggest replacing all of the instances of "provably
[un]signed" with "provably [in]secure".   To me, a zone is provably signed
if it has DNSKEYs and RRSIGs that validate from those DNSKEYs.  What the
draft is interested in is whether those signatures link up to a trust
anchor somewhere, and the term for that is "secure".  But maybe there are
definitions somewhere that I haven't read that make "signed" and "secure"
equivalent, which would make this a silly suggestion.

Section 5 discussion: I can't remember if I commented on this bit before or
not, but just in case.. I support keeping the reserved field.  It seems to
me that if we have to get a new type for an incremental-friendly version of
ZONEMD that we're going to have implementation fragmentation and a
migration issue.  Especially if we don't allow multiple ZONEMD records, I
can imagine it being difficult to have both in the zone at once, and that
it could be hard to specify what should happen if an operator wants to
migrate from ZONEMD v1 to ZONEMD v2 without knowing which one the consumers
of their zone support
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-wessels-dns-zone-digest

[Matthew Pounsett]

On Sun, 10 Mar 2019 at 15:31, Tim Wicinski  wrote:

>
> This starts a Call for Adoption for draft-wessels-dns-zone-digest
>

I believe DNSOP should adopt this draft.


> Please also indicate if you are willing to contribute text, review, etc.
>

I am willing to review and contribute text.

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

Re: [DNSOP] [Ext] Re: New draft for consideration:

[Matthew Pounsett]

On Sun, 24 Mar 2019 at 17:17, Joel Jaeggli  wrote:

>
>
> On Mar 24, 2019, at 08:59, Matthew Pounsett  wrote:
>
>
>
> On Sun, 24 Mar 2019 at 11:46, Paul Hoffman  wrote:
>
>>
>> > I'm also not too hot for conflating "user consciously changes
>> > /etc/resolv.conf or equivalent" with "application makes the choice for
>> the
>> > user".
>>
>> The split here is more "someone changes from traditional without the user
>> knowing, when the user cares". If you have a better way to express that,
>> that would be great.
>>
>> > Perhaps we should talk about 'Per-application stubs'? Because this is
>> the
>> > nub.
>>
>> Maybe, but I'm hesitant to make the break that way because some
>> applications' stubs use the traditional resolver, others don't. I would be
>> hesitant to conflate those two.
>>
>
> I don't think the current wording for DaO expresses the same point that
> you've made here.  In particular, mentioning that DaO might refer to a user
> modifying /etc/resolv.conf is inconsistent with the intent that DaO is
> sending queries somewhere other than where the traditional configuration
> says.  /etc/resolv.conf (and its equivalents in non-unix OSes) *are* the
> traditional place to configure that.  Whatever that file says, I think any
> resolver that is consulting that file to find its upstreams is doing DaT.
>
>
> I think we’re at the point where using acronyms is is obscuring the detail
> of what is being described. If and acronym describes a protocol or an
> architectural feature that is unambiguous, great.
>
>
> How about:
>DaO: DNS resolution between a stub resolver and a recursive resolver
> that
>differs from the recursive resolver configured in the traditional
>location(s) for a system.
>
>
> This describes a multitude of systems of varying implementation. It would
> seem for example to include bonjour, a tor client, some vpns and many
> operating system container environments.
>

I may be wrong, but I don't believe bonjour uses RDoT or DoH.

The VPNs you reference are, I think, intended to be covered by the term, so
I think the definition works there.

 I don't think I have an opinion on whether Tor should or shouldn't be
covered by the definition (although others might), so if you wanted to
suggest text that excluded it I think people would consider that.

I don't think container environments are included in the definition either,
because in a container environment the container's resolution path is the
traditional point of configuration for that type of system.  Perhaps the
word "traditional" is too ambiguous, and leads people to think more
"historical" than "typical"?


>
> DaO can be configured by a user changing where a
>stub resolver gets its list of recursive servers, or an application
> running
>RDoT or DoH to a resolver that is not the same as the resolver
> configured
>in the traditional location for the operating system.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: New draft for consideration:

[Matthew Pounsett]

On Sun, 24 Mar 2019 at 11:46, Paul Hoffman  wrote:

>
> > I'm also not too hot for conflating "user consciously changes
> > /etc/resolv.conf or equivalent" with "application makes the choice for
> the
> > user".
>
> The split here is more "someone changes from traditional without the user
> knowing, when the user cares". If you have a better way to express that,
> that would be great.
>
> > Perhaps we should talk about 'Per-application stubs'? Because this is the
> > nub.
>
> Maybe, but I'm hesitant to make the break that way because some
> applications' stubs use the traditional resolver, others don't. I would be
> hesitant to conflate those two.
>

I don't think the current wording for DaO expresses the same point that
you've made here.  In particular, mentioning that DaO might refer to a user
modifying /etc/resolv.conf is inconsistent with the intent that DaO is
sending queries somewhere other than where the traditional configuration
says.  /etc/resolv.conf (and its equivalents in non-unix OSes) *are* the
traditional place to configure that.  Whatever that file says, I think any
resolver that is consulting that file to find its upstreams is doing DaT.

How about:
   DaO: DNS resolution between a stub resolver and a recursive resolver that
   differs from the recursive resolver configured in the traditional
   location(s) for a system.  DaO can be configured by a user changing
where a
   stub resolver gets its list of recursive servers, or an application
running
   RDoT or DoH to a resolver that is not the same as the resolver configured
   in the traditional location for the operating system.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthew Pounsett]

On Sat, 23 Mar 2019 at 14:08, Paul Vixie  wrote:

> Bind9 with no config file now does the right recursive thing, including
> dnssec. Knot and unbound and powerdns will not be far behind. We just need
> to get the word out, to ISPs, Enterprise, SOHO, and end users of Windows,
> macosx, Linux, and BSD. The hard part will be iOS and Android, due to the
> permission model and app stores. Those can be last.
>

There are rumours that Apple is at least considering DANE
implementations[0] for their mobile and desktop browsers.  If that comes to
pass you'll see DNSSEC validation on iOS a lot sooner than you think.
Anyone who has any customer influence with Apple could possibly push them
in that direction... enough large customers pushing might inch them toward
that ledge.

[0]: <
https://lists.dns-oarc.net/pipermail/dns-operations/2019-January/018298.html
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthew Pounsett]

On Wed, 20 Mar 2019 at 07:38, Joe Abley  wrote:

> [There is actually a proposal at the bottom of this e-mail. Bear with me.]
>

And it's a good proposal!


>
> Standardise this privacy mechanism, and specify (with reasoning) that it
> should be implemented such that the existence of the channel (but not the
> content) can be identified as distinct from other traffic by third parties.
> Maybe specify use of a different port number, as was done with DoT.
>

I think this would alleviate most people's concerns... certainly it deals
wth mine.  I have difficulty believing it is acceptable to pro-DoH
community though, considering the first of the two use-cases defined in the
Introduction of RFC8484: "... preventing on-path devices from interfering
with DNS operations..."

I eagerly welcome the -bis document that removes this statement, and
defines a new port number which DoH traffic SHOULD use.

Those who choose to ignore that direction and create a covert channel using
> port 443 instead will do so. Nothing much we can do to stop that today (I
> guarantee it is already happening). The future is not really different.
>

Indeed.  If everyone above-board is using port 5443 (to pull a number out
of the air) for their DoH traffic, the below-board usage should be about as
visible as any such usage is today.

Of course when people shift the focus of the conversation from DoH in
> general to resolverless DNS, and want to interleave DNS messages with HTML
> and cat GIFs over the same HTTPS bundles, the pitchforks will need to come
> out again. So keep them handy.
>

I don't actually own a pitchfork, but I'll keep my Woodsman's Pal sharp. :)

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

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

[Matthew Pounsett]

On Tue, 19 Mar 2019 at 13:45, Ted Hardie  wrote:

>
>> I have a relationship with my users and I can control the configuration
>> of their *known* applications.  I do not have a relationship with the
>> malware author that is trying to steal their data, and cannot control the
>> configuration of that (unknown) application.  By running DoT on my borders
>> and blocking all other DNS and DoT traffic, I can provide privacy for my
>> users while still preventing malware from doing its thing.
>>
>
> As I said to Paul, I don't think you can if your only defense is blocking
> DNS access.  Coding a system to use a non-standard resolution protocol over
> TLS is relatively easy; all the malware needs is a specific target to start
> at.  That target can be hard coded, derived from the output of a web
> search, or produced by the output of an algorithm resident in the malware
> and some system-available data (commonly the time).  My apologies if I have
> misunderstood your point here, but unless you also block all traffic for
> which you have seen no resolution event, I believe that it is entirely
> possible to circumvent the defense you describe.
>

I think you need to understand a bit of the history of malware development
and the arms race to block it.

Malware C started out at hard-coded IP addresses.  They quickly realized
this didn't work because going to a single address for your C is easily
spotted, easily filtered, and easily taken down.  So they moved to using
domain names and DNS; they could change the IP addresses that their C
domains resolved to very quickly, and move C around, avoiding takedown.
After a while, the domain sales business got better at domain takedowns,
and so malware developers moved from single domains to DGAs.  Which is
where we are today.

Using a hard-coded endpoint for domain resolution, even if it's TLS
encrypted, is as easily spotted and dealt with as using a single hard-coded
endpoint for C it can be filtered as soon as the anomaly is detected.
Using DGAs to bootstrap such hidden resolution systems has the same
limitations as DGAs above.  It's just adding an extra layer of abstraction,
using identical systems, over the C in the first place.  The fact that
they are NOT doing this today, even in the face of domain reputation
systems and RPZ feeds should tell you something.  I'd bet any malware
author who's though of doing what you suggest got at most a few dozen lines
into writing the code, realized they were just reimplementing their
existing C, and stopped.


>
>
>> With DoH available at endpoints that my users want to reach using some
>> other application,
>>
>
> And this is the critique that is not of DoH as a protocol, but of a
> specific deployment possibility.  You've seen the Quad9 folks point and the
> Chrome statement of their current deployment plans.  The first said they
> will not deploy DNS resources and other web resources on commingled hosts.
> The second said that they will only use DoH after a probe reveals that it
> is available *at the already configured DNS service*.  This is entirely in
> line with Section 3 of RFC 8484:
>

Quad9 and Chrome's current policies are no guarantee of their future
policies, nor the policies of other major browser developers or web
properties.  I cannot assume a statement made by either organization is
binding on the entire Internet.

When have you ever seen the Internet writ large choose NOT to do a thing
that was enabled by the technology?  The protocol enables (and even
encourages) the deployment possibility, so why shouldn't I expect it?  As
soon as DoH the protocol is in GA codebase of major web browsers there will
immediately be enough uptake on DoH server operation to enable the thing
operators are concerned about.  And remember, the protocol is DESIGNED to
inhibit interference by hiding resolution streams along side other, less
easily blocked traffic.  You seem to be making the argument here, "don't
worry, you'll still be able to interfere with DoH resolution by clients you
don't control."  If so, that is disingenuous at best.

>A DoH client MUST NOT use a different URI simply because it was
>discovered outside of the client's configuration (such as through
>HTTP/2 server push) or because a server offers an unsolicited
>response that appears to be a valid answer to a DNS query.  This
>specification does not extend DNS resolution privileges to URIs that
>are not recognized by the DoH client as configured URIs.
>
>
> Browsers do not have an incentive to permit random websites to poison
> their caches, so I strongly suspect that there will be no ability to pass a
> resolution done in JavaScript down into the browser cache; my experience
> during RTCWeb was that the browsers treated all downloaded JavaScript
> applications as potentially malign.
>

As I (and others) have stated several times, browsers aren't the ultimate
problem.  They will be configurable and thus controllable, when they're
cooperative.  

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

[Matthew Pounsett]

On Tue, 19 Mar 2019 at 13:37, Christian Huitema  wrote:

>
> On 3/19/2019 12:50 AM, Eliot Lear wrote:
>
> On 19 Mar 2019, at 01:50, Matthew Pounsett  wrote:
>
> Somewhere up-thread it was suggested that there are other reasonable steps
> that a network/security operator can take to maintain the controls over
> resolution that we have today, but so far I haven't seen them enumerated
> anywhere.
>
>
> I had stated that one can use an MDM to manage the endpoint’s use of DoH.
> This doesn’t eliminate the possibility of malware, but does reduce
> misconfiguration in the enterprise, and provides for some protection
> against infection by blocking known bad names.
>
> Configuration works well for functions like "phishing protection": the
> device users in most cases want some form of protection, and then it is a
> matter of how this protection is configured. It does not work so well for
> functions like intrusion detection, such as figuring out whether a device
> is trying to contact a botnet C, because we cannot expect the infected
> device to be amenable to configuration.
>
Yes.  I'm not particularly concerned about cooperative clients.  Even if
it's not possible today, the economics of large enterprises will force
browsers et. al. to make their software configurable in some automated,
mass-update way that works for 50k+ employee companies.  I'll be able to
use the same controls to force cooperative clients to use my resolver,
whether that be DoT or DoH.

It's the uncooperative clients that I'm concerned about, and the presence
of DoH endpoints at the same IP:port pair as other web sites means that in
order to deal with uncooperative clients, operators will have to
block/proxy all external port 443 traffic in order to make sure malware
can't get access to resolution they don't control.

In addition, there’s at least a heuristic for detection: compare data plane
> activity against ANSWERs.  If you’re seeing activity to addresses that
> don’t match (modulo some noise), you know an alternate resolver is active
> on that device.  And while it’s possible for malware to mimic queries to
> Do53 for Good sites versus what it really wants to access, you start
> tarnishing the rep of the IP address as and when you detect the problem
> through other means (AV s/w, honey pots, binary inspection, et al).  That
> leaves it with cloud providers to sort their wagons.
>
> Yes, one could imagine IP address or IP prefix reputation systems, similar
> to the IP address block lists used to protect against spam. This would
> work, and it would also provide intrusion detection signals when an
> infected device starts contacting a botnet. The problem of course is the
> gray line between "blocking phishing sites" and "blocking content that I
> disagree with". The various attempts to block the whole of Wikipedia in
> order to block some specific pages shows where this can lead.
>
The distinction between blocking single pages vs. blocking whole domains
isn't really relevant here since we're talking about DNS-based blocking in
the first place.  However, there's a similar problem between blocking
domain resolution and blocking the IP address a domain resolves to.  Right
now operators can block access to malwareCnC.com even if it resides on the
same web server as useful.website.net because of the way virtual hosting
works.  If operators have to replace their domain reputation feeds with
address reputation feeds there's going to be less fine-grained control and
collateral damage.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthew Pounsett]

On Fri, 15 Mar 2019 at 14:37, Ted Hardie  wrote:

>
>> The past five years have not been the IETF seeking to become a king or
> king-maker.  They have been spent responding to an attack while still
> building out the facilities of the network.  I am glad to find you a ready
> participant now, as there is still work to be done.  But I do not believe
> we have said that you may not have these facilities; the new methods simply
> mean you must have a relationship with the users and devices on your
> network sufficient to effect configuration to use them.  An on-path
> adversary does not, but you do.  Yes, that adds a step and some complexity,
> but dealing with a new class of attack was never likely to be free.
>

This, again, conflates users with attackers.

I'm going to take a stab at restating the positions of several people in
this thread, Paul included, because it really seems like the argument is
not understood.

I have a relationship with my users and I can control the configuration of
their *known* applications.  I do not have a relationship with the malware
author that is trying to steal their data, and cannot control the
configuration of that (unknown) application.  By running DoT on my borders
and blocking all other DNS and DoT traffic, I can provide privacy for my
users while still preventing malware from doing its thing.  With DoH
available at endpoints that my users want to reach using some other
application, it is orders of magnitude more complex for me to block the
malware while still allowing my users to reach those endpoints.  Phrased
another way, a DoH endpoint at the same IP address as a popular website
gives malware the ability to resolve names I was previously able to
prevent.  The only recourse I know of, if DoH is adopted, is to proxy all
traffic toward that example site (including requiring me to engage in a
MitM decryption attack on my users' web traffic) in order to continue to
prevent that malware from circumventing network security.  And because I
can't predict which web sites will launch their own DoH endpoints, that
means I need to proxy (and decrypt) all web traffic in order to maintain
the same level of security I can today.

Somewhere up-thread it was suggested that there are other reasonable steps
that a network/security operator can take to maintain the controls over
resolution that we have today, but so far I haven't seen them enumerated
anywhere.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC 2845bis and HMAC-MD5

[Matthew Pounsett]

On Thu, 14 Mar 2019 at 11:08, Tony Finch  wrote:

> Martin Hoffmann  wrote:
> >
> > As such, I would like to propose to move HMAC-MD5 to optional and only
> > retain SHA-1 and SHA-256 as mandatory.
>
> That seems sensible. There should at the very least be a reference to
> RFC6151, Updated Security Considerations for the MD5 Message-Digest and
> the HMAC-MD5 Algorithms.
>

Agreed.  I can't remember the last time I generated an HMAC-MD5 key .. and
I believe the default behaviour for most (all?) recent major distributions
default to something stronger (e.g. BIND now defaults to HMAC-SHA256).  Any
operators needing to support old key algorithms would be free to use
distributions that continue to optionally support them, or generate and
distribute new keys (something that should be done periodically anyway).
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Any website publishers who use CDNs on the list?

[Matthew Pounsett]

On Mon, 5 Nov 2018 at 06:11, Vladimír Čunát 
wrote:

> On 11/2/18 10:41 PM, Evan Hunt wrote:
> > Speaking as a co-author of ANAME, I agree about this. URI, SRV, a
> proposed
> > new HTTP RRtype, whatever - service lookup is absolutely the correct way
> to
> > accomplish this goal.
> >
> > However, browser vendors are *not doing that*, and I've given up hope
> that
> > they ever will. Trying to out-stubborn them has been ineffective.
>
> Yes, but I can understand that they're not too inclined - I believe it's
> not easy to portably get information about such RRTYPEs from the OS
> resolver, e.g. I can't see a way in POSIX.  Most http libraries would
> need to deal with this somehow.  It doesn't seem realistic to *wait* for
> OS implementations or even APIs to improve.  Overall it seems quite a
> stalemate, I'm afraid, probably without an "ideal" solution within
> reasonable timeframe.
>

Can you point to a major browser that does *not* implement its own resolver
already?

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

Re: [DNSOP] Minimum viable ANAME

[Matthew Pounsett]

On 21 September 2018 at 09:12, Dan York  wrote:

>
> I do think this is a path we need to go.  We need *something* like CNAME
> at the apex.  Either CNAME itself or something that works in the same way
> but might have a different name.
>

I would still like to see something SRV-like for HTTP, but I realize that's
going to be a long slog .. getting the HTTP folks on board, and getting it
defined and deployed.  I don't see any value in pursuing re-defining CNAME,
because the install-base prevents that from being useful to anyone until a
significant number of recursive resolvers are updated. So.. I think ANAME
is the short term solution we need.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

[Matthew Pounsett]

This is not a complete review of the latest revision.. I'm hoping to get to
that in a day or two.   But I've got a question about whether something
should be added to the document..

A question came up in conversation recently about the use of the verb "to
publish" in reference to managing DNS data.  It quickly became clear that
there may be a common overloading of terms, where the same word means
different things to different people.  I wasn't sure this fell into the
scope of the terminology document, but I just checked and it does use
"publish" in reference to DNS data, so perhaps we should come up with a
definition for that.

To me, publishing DNS data has always meant the generation of the zone and
the data it contains, as distinct from distributing the zone (to name
servers, possibly though zone transfer) and serving the zone (making it
available to be queried on a name server).  To the person I was speaking
to, "publishing" meant putting that data on Internet-facing name servers
that would answer queries about it.

However, using such a broad definition of "publishing" seems, to me, to
introduce confusion in that it removes a clear distinction between the
steps of generating data, distributing those data, and then making them
available to be queried.  To draw a comparison, one might look to the steps
of writing, publishing, distributing, and selling a book (although I'm not
sure how the first two would map differently to publishing DNS data.. they
seem like the same step to me in this context).
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt

[Matthew Pounsett]

On 7 June 2018 at 15:33, Viktor Dukhovni  wrote:

> >
> > I hope it is now clearer why we are doing this?
>
> Well, I see that we end up with a bit less code-point diversity,
> but in this case 8/10 are barely different and require the same
> supporting code.  So while I'm not strongly advocating 10, I see
> it just a "tweak" of 8, and would expect to not differentiate
> between them, use either, interoperate with neither or both...
>
> Again, this comment is not an objection just saying that I would
> have treated 8 and 10 as interchangeable.
>
> Except that they are not interchangeable, and algorithm rolls are
operationally expensive.  Anyone doing an algo roll from 8 to 10 is less
likely to want to do one again any time soon. Since there is little gain
from moving to 10, it's better to discourage use of 10 in order to
encourage–and make it easier for–operators to use their algo rolls to move
to ECC instead.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

[Matthew Pounsett]

On 16 May 2018 at 14:51, Viktor Dukhovni  wrote:

>
>
>
> I can make a list...  Should it go in this draft, or should I work with
> Patrick Wallstrom to flesh out that draft?  Will this draft reference
> the other one?
>
> General DNSSEC hygeine is out of scope for this draft, so better that you
work with Patrick.  The draft already references
draft-wallstrom-dnsop-dns-delegation-requirements in the bootstrapping
section.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?

[Matthew Pounsett]

On 15 May 2018 at 12:34, Tony Finch  wrote:

> Ted Lemon  wrote:
>
> > It might be useful to compare this to labels like _tcp that appear in SRV
> > records and elsewhere.
>
> The reason for listing a name in the RCF 6761 registry is because it needs
> special handling of some kind in DNS software. That isn't the case for the
> _underscore names, which (from the DNS point of view) are just ordinary
> domain names that have conventional uses in applications.
>
> I'm going to suggest a modification to your first sentence.  The reason
for listing a name int he RFC 6761 registry is because it needs special
handling of some kind in DNS software that would otherwise be unaware of
the special handling required by that name.  In this case, the only name
servers that need to handle these names specially are the ones implementing
the technology.. all other name servers treat them as ordinary names.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?

[Matthew Pounsett]

On 14 May 2018 at 14:10, Warren Kumari  wrote:

>
> So, please, *clearly* state if you think that this:
> A: is a SUN
> B: is not a SUN
>
>
> I think this is not a SUN.

6761 has a lot of opportunity in its text to refer to leftmost labels and
doesn't do that, not even in what could have been fairly obvious examples
(e.g. localhost.*).  Also, the SRV registry is not encapsulated in the SUDN
registry, and that seems to me to be the same issue.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Lameness terminology

[Matthew Pounsett]

On 4 May 2018 at 05:59, Shane Kerr  wrote:

>
>
> Within a given NS RRset for a zone, we have a few failure modes:
>
> A. One or more NS do not resolve
> B. NS RR points to a CNAME (technically disallowed, right?)
> C. NS RR does not point to any A or  that resolve
> D. An A or  RR is for one or more addresses that are not
>authoritative
>
> Case C might not strictly be lame, if for example it points to a .ONION
> address or similar.
>
> Case D might be usefully split into addresses that reply and those that
> timeout.
>

That seems complete to me.


> I think that there may be something useful in creating a term when a
> delegation only points to lame servers, thus cannot be resolved at all.
> Perhaps "broken delegation"? 
>

The way this has always worked in my head is that a zone can be delegated
to one or more lame servers.  If the zone is delegated entirely to lame
servers, then the delegation is lame.

But I take your point that perhaps that is too much overloading of the term
'lame'.




>
>
> There are also a few related issues coming from mismatches at parent &
> child.
>
> 1. "Lame hint" might describe an NS that is above the zone cut, and
>points to one or more lame servers
>

The NS set above the zone cut comprises the delegation, doesn't it?  That's
not just a hint.


> 2. "Authoritatively lame" might describe an NS that is below the zone
>cut
> 3. "Totally lame, man" might describe a lame NS that is in both
>
> We can also have:
>
> 4. "Confusingly lame" which might describe when there is a mismatch
>between NS answers of authoritative servers, some of which point to
>lame servers 
>

Now I don't feel so bad about using 'lame server' and 'lame delegation' to
mean not-entirely-overlapping things. :)


>
>
> I hesitate to suggest it, but is there value in a draft around lameness?
>
> There's value in describing common misconfigurations and how to
detect/name/avoid them.  Does it need to just be a draft about lameness?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC 6781 Errata?

[Matthew Pounsett]

On 2 May 2018 at 04:35, Matthijs Mekking  wrote:

> I think the line:
>
> After that DS RR has been
> published on all servers authoritative for the parent's zone, the
> zone administrator has to wait at least TTL_DS to make sure that
> the old DS RR has expired from caches.
>
> Could be part of the 'DS change' step.
>
> It qualifies as an errata IMHO.
>

I went and looked and someone beat me to it by a couple of years.. I just
didn't notice that errata on the first read.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

[Matthew Pounsett]

On 14 April 2018 at 17:05, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:

>
>
> > On Apr 14, 2018, at 4:26 PM, Matthew Pounsett <m...@conundrum.com>
> wrote:
> >
> > These are getting into name server quality checks, and not security
> checks, which is the point of the acceptance testing.  I don't agree that
> these should be part of this document.
>
> If the registry operator is going to automatically upgrade previously
> insecure delegations to DNSSEC, then due diligence to make sure that this
> is not going to cause outages is advisable.  Once a domain is signed, TLSA
> and CAA lookups must succeed, or the domain may no longer receive email
> from DANE-enabled sending MTAs, or be able to obtain certificates from
> their CA, ...
>
> So I rather strongly feel that appropriate quality checks should be in
> place, to protect both the registrant and the registry (dealing with
> fallout from outages is best avoided).
>

Except that those are standard DNSSEC operations best practices, not even
limited to CDS use, let alone a REST protocol designed for signalling that
CDS should be scanned.  Perhaps others can speak up about the applicability
here, but I feel rather strongly that general operations best practices
shouldn't be defined in a document limited to one corner case.  That risks
the advice case either not being applied elsewhere, because it's not in a
general operations document and therefore not seen, or worse contradicting
what goes into a general operations document.

The security checks in this draft are there to help ensure that the parent
can trust the update request.  I believe going further than that is out of
scope.

I think if you want there to be guidance that parents should check on the
quality of the child operations that should
1) come from DNSOP, not REGEX, and
2) be in a document about general DNSSEC operations.

We currently ref out to draft-wallstrom-dnsop-dns-delegation-requirements
in that section (we're hoping that draft continues to go somewhere so we
don't have to import too much of its text directly, although it has been
expired for a year now).  You might want to submit some text there.. or
angle for something that updates (or is a -ter for) RFC6781.


> >
> > While this is probably a reasonable thing to do, a registration
> mechanism documented in REGEXT is not the place to do this.  I think if
> DNSOP wants such advice in a standard there should be a BCP document out of
> DNSOP that defines it.
>
> Yes, this is a point for discussion.  Still I think it would be bad to,
> for example, introduce more domains with 512-bit RSA keys, or perhaps even
> accept 1024-bit RSA
> keys.  There are many domains with 1536-bit KSKs and 1280-bit ZSKs, these
> are I
> think well chosen, though ECDSA P-256 (algorithm 13) is looking
> increasingly like
> an even better choice at present.
>
> Given that 1024-bit RSA is considered past its use-by these days, perhaps
> limiting
> automated upgrades to DNSSEC only to stronger keys is a good idea???
>

But again, that's a general operations issue, and not one limited to this
signalling mechanism.


>
> >>   o Check that if the zone uses NSEC3 the NSEC3PARAM iteration
> count is
> >> at most 150 (regardless of RSA key size).  Larger iteration
> counts
> >> are both inefficient and fragile in the face of algorithm
> rollovers.
> >> The optimal value is 0 (performs one round of SHA1, which is
> enough to
> >> deter casual zone walking).  The most popular value is 1, which
> is
> >> very likely because it is slightly unclear whether 0 means no
> hash
> >> or (as is the case) just one initial hash.  So hats off to the
> >> operations that chose 1, they understand that the count should
> be
> >> low, and are careful to avoid edge cases.
> >
> > Again, I think this is out of scope of a document standardizing a
> registration mechanism.  Besides which, there are operators out there who
> deliberately have a low iteration count because they don't care about zone
> walking, and are only using NSEC3 for the opt-out capability.
>
> Here you misunderstood my point, I am suggesting a MAXIMUM of 150 and
> recommending
> 0 or 1, precisely because opt-out is mostly all that NSEC3 is useful for,
> but one
> or two rounds of SHA deter "casual" zone walking.
>

Yes, for some reason I got your intent backwards.  I still think it's out
of scope though... an iteration count higher than 150 does not constitute a
trustworthiness problem for the parent.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] RFC 6781 Errata?

[Matthew Pounsett]

I've found some confusing text in the KSK Rollover section of RFC 6781, and
I'm trying to decide whether to submit it as errata.

In section 4.1.2, which describes the various steps in a KSK rollover, the
following text is meant to describe the last three steps:

   new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
  generates a second KSK, DNSKEY_K_2.  The key is provided to the
  parent, and the child will have to wait until a new DS RR has been
  generated that points to DNSKEY_K_2.  After that DS RR has been
  published on all servers authoritative for the parent's zone, the
  zone administrator has to wait at least TTL_DS to make sure that
  the old DS RR has expired from caches.

   DS change:  The parent replaces DS_K_1 with DS_K_2.

   DNSKEY removal:  DNSKEY_K_1 has been removed.


The text for the "new DNSKEY" step seems to contain text that belongs in
the other two.  Even though rearranging it wouldn't change the meaning,
it's not clear to me that this qualifies as simple errata.. it's obviously
too big a change to just be fixing a typo.

Thoughts on whether I should submit it?

Or maybe we just put it on the pile of things that have come up recently
that speak to a 6781-bis document.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

[Matthew Pounsett]

On 14 April 2018 at 12:54, Viktor Dukhovni  wrote:

>
> A number of checks are listed in:
>
>   https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-
> to-rrr-protocol-04#section-3.4
>
> that are intended to make sure a domain is ready for DNSSEC.
>
> As I've been the DNSSEC and DANE implementations at now ~5.8 million
> domains, I'd like to suggest some additional checks:
>

Thanks for the review Viktor. We haven't had many DNS people respond to the
draft.. I've been considering mentioning it in DNSOP, but was going to wait
until several pending changes are in the doc and -05 is out (hopefully in
the next week or two, time permitting).


>
>  o  ensuring that the SOA record RRset is correctly signed, unlike:
>
>   http://dnsviz.net/d/_25._tcp.mx1.techtrack.gov/dnssec/
>
> which is always incremented by 1 *after* the zone is signed!
>

I believe this is already covered by the first point: "checks that the
child zone is is properly signed as per the Registration Entity and parent
DNSSEC policies".  Although, we could add some example RRsets that should
be examined for correct signatures.


>  o  ensuring the NS RRset at the zone apex matches the glue RRs
> at the parent zone


>  o  Verifying that TLSA lookups are NOT blocked and denial of
> existence works by querying for:
>
>_25._tcp..example.net. IN TLSA ?
>
> and verifying the NXDomain, NODATA, or (very rarely) wildcard
> TLSA records against the implied DNSKEYs.  The nonce can be some
> random hex string of 8 or more bytes, that is unlikely to be an
> actual name in the zone.
>
>   o Do the above for all IPv4 and IPv6 addresses of all the
> nameservers,
> as some misconfigured firewalls block unexpected RR types for just
> IPv4 or just IPv6.
>
>   o A similar probe for CAA records is likely appropriate, Let's
> Encrypt
> runs into CAA lookup issues for a non-negligible fraction of
> domains.
>

These are getting into name server quality checks, and not security checks,
which is the point of the acceptance testing.  I don't agree that these
should be part of this document.


>
>   o Check that if the zone uses RSA, the KSK and ZSK are at least 1280
> bits and at most 2048 bits.  This may be controversial, but for new
> deployments RSA <= 1024 bits is widely considered too weak, and RSA
> with more than 2048 bits creates signatures that are often too
> large
> for reliable UDP transport.
>

While this is probably a reasonable thing to do, a registration mechanism
documented in REGEXT is not the place to do this.  I think if DNSOP wants
such advice in a standard there should be a BCP document out of DNSOP that
defines it.


>
>   o Check that if the zone uses NSEC3 the NSEC3PARAM iteration count is
> at most 150 (regardless of RSA key size).  Larger iteration counts
> are both inefficient and fragile in the face of algorithm
> rollovers.
> The optimal value is 0 (performs one round of SHA1, which is
> enough to
> deter casual zone walking).  The most popular value is 1, which is
> very likely because it is slightly unclear whether 0 means no hash
> or (as is the case) just one initial hash.  So hats off to the
> operations that chose 1, they understand that the count should be
> low, and are careful to avoid edge cases.
>

Again, I think this is out of scope of a document standardizing a
registration mechanism.  Besides which, there are operators out there who
deliberately have a low iteration count because they don't care about zone
walking, and are only using NSEC3 for the opt-out capability.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[Matthew Pounsett]

On 13 April 2018 at 11:11, bert hubert  wrote:

> > >1) chase CNAMEs that point to another zone
> > >2) look for glue outside of the zone
> >
> > 1) What was the historical text that indicated that an authoritative
> server
> > should chase CNAMEs before responding? This worries me.
>
> RFC 1034, 4.3.2, step 3, a. It says to go back to step 1, which means that
> in step 2 we look up the best zone again for the target of the CNAME. I
> have
> not looked if newer RFCs deprecate this or not. So with 'chase' I mean,
> consult other zones it is authoritative for. There might be millions of
> these btw, operated by other people.
>

Wouldn't there be a security concern with doing that?

Let's say you're a DNS hosting company and I get you to host example.com
for me, and delegate it to your servers.  For some good, but obscure reason
I have:
update.example.com IN CNAME update.microsoft.com.

An attacker comes along and asks you to host microsoft.com, which is not
delegated to you.  They have:
update.microsoft.com IN CNAME attack.badguy.com.

If you follow CNAME chains outside the zone (but inside the "authoritative"
zones in your server) then you have just participated in redirecting a
CNAME chain away from where it's supposed to go.  Either recursive servers
will trust your supplied CNAME chain and their users will be attacked, or
they will (rightly) not trust you and go look up update.microsoft.com
themselves, which, in which case you have wasted resources looking it up in
your own.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Current DNS standards, drafts & charter

[Matthew Pounsett]

On 31 March 2018 at 17:34, bert hubert  wrote:

> First, I agree it is necessary. I don't think anyone would really disagree.
> The issue is the stupendous amount of work it would be and if we are going
> to do it.
>
> A secondary question is how hard we are going to make this on ourselves if
> we do it. This comprises a number of things: 1) which RFCs would be
> obsoleted
> by the rewrite (2181?)and which ones are we going to leave in place (403x?)
>
> 2) What 'optional' things are we going to move into scope of DNS basics. In
> other words, what will 1034/1035-bis say about DNSSEC?
>
>
> I think that's another question of organization in here too, which is
whether the document is operations or implementation, and if it's
implementation what part of the architecture is being implemented (e.g.
client, server, authority, recursion, ...).

I can't decide whether it makes more sense to split up things like stubs,
full resolvers, or authoritative servers into separate documents, or to try
to describe the whole beast in one document like 1035 did.  But, for the
core, I'm leaning toward the former.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Current DNS standards, drafts & charter

[Matthew Pounsett]

On 31 March 2018 at 22:02, Paul Vixie  wrote:

>
> furthermore, the IETF would have to update some STD document every time a
> new DNS-related RFC was published, just to enumerate the full set of things
> a new implementer should study and consider. that STD could be just a list
> of RFC's, or could mention specific sections and say they are "in" or
> "out", or could repeat the relevant text. i could argue for any of those
> three approaches. but your model requires one of those, or else, "read them
> all and let the market sort it out" is our guidance to new implementers.
> that's what's not working now, and won't work, ever.
>

No.  None of that is required by my suggestion.  "Scan the Introduction"
perhaps, but not "read them all."   All that would have been required to
make our current situation less problematic is a few phrases like "this RFC
obsoletes section X.Y of RFC Z" or "this RFC should be read as if it is
section A.B.D after section A.B.C in RFC Z" in anything with Updates
meta-data.  And your assertion that we'd need some STD to be repeatedly
updated is obviated by something like "this RFC (is|is not) considered
mandatory to implement for the DNS protocol."

Non-IETF documents that summarize RFCs, collect them into useful
categories, or cherry-pick sections to create a "core" standard are useful
to us now because we didn't deal with these things while writing the RFCs
that we have today.  Adding a bit of rigour to what we submit to last call
could make those things optional tomorrow.  External documentation might
always have some use as a primer, summary, walkthorugh, or historical
context, but unless you're giving up on the IETF entirely I think it's a
worthy goal to try to produce a document set that doesn't *require*
external documentation to make it clear.  And if you're going to say that
external documentation will always be required, and that we can't possibly
create documents that don't require it, then I think that's giving up on
the IETF and we might as well skip this process and use that one instead.
I, for one, would rather only work on the documents once.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Current DNS standards, drafts & charter

[Matthew Pounsett]

On 28 March 2018 at 14:48, Paul Vixie  wrote:

> matt, the rfc document set is innately time-series. this was seen as a
> strength compared to some "document set in the sky" that would be updated
> periodically with lineouts and additions, like for example legal codes or
> the ARIN PPML. i think you're very close to saying we need the latter in
> addition to the former, and if so, then i agree with you, but this is an
> IETF problem not a DNSOP problem. --paul
>

I think the RFC series as a whole needs to contain both, but I'm not saying
that both should exist simultaneously for any given set of documents within
the RFC series.  I think we've reached a point where the time series for
DNS has become so complex and convoluted that it's time for a reset to make
it readable again.  We can then carry on patching that with time-series
documents if we want, but the rewrite will give us a new baseline that's
coherent and complete, which we don't have today.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Current DNS standards, drafts & charter

[Matthew Pounsett]

On 27 March 2018 at 20:17, Paul Vixie  wrote:

> I think we're discussing the same idea from different perspectives.
>>
>
> i think so, yes.
>
> I think writing a new document that references other documents to say
>> "here's the sections in each of these you need to implement" without
>> actually making any of them clearer is unhelpful, and just adds to the
>> pile of documents that an implementer needs to read.
>>
>
> that's not what i heard bert propose, and it's not what i'm thinking.
> where an older document is not clear, its intent should be restated in
> modern language with modern understanding. where an older document is
> clear, we can refer back to it. if the balance ever tips, then some future
> generation of protocol developers can obsolete older documents in their
> entirety, because the useful parts have all been restated or cut and pasted.


So yes.. we are on roughly the same page.  I'm not a huge fan of meta-RFC
reading lists, even for documents that are fairly clear, but it's hugely
preferable to the current situation.

One of the things I have never liked about the RFC series is the lack of
clarity in an Update document.  I always thought an RFC that Updates
another should be required to state unequivocally which sections of the
older document are obsoleted or, which "new" sections of the older document
the new document creates.  Changing a section in part should never have
been allowed.

Creating those references where they don't already exist and putting them
in a new RFC potentially increases clarity, but also increases the
complexity of the reading material; I'd much prefer we reduce both.


>
>
> While I recognize there's already been one failed attempt at this,
>> I'd still much prefer we replace as much of that stack as possible
>> with a smaller set of clearer documents.
>>
>
> this is what i want. we should aim for a living RFC that's reissued from
> time to time as the mandatory-to-implement subset inevitably grows. i have
> no appetite for obsoleting 1035, but i do want a new implementer to be
> referring to it as directed by a more modern document, rather than reading
> it and wondering what parts are still in effect.
>

I think 1035 is the prime candidate for being obsoleted by new documents.
It's been updated and clarified so many times, and there are so many
undocumented workarounds of its underspecification, that the reading
required to understand what parts of it are in force is incredibly
discouraging.  There are lots of more modern documents that can stand on
their own as long as they are updating a clear core specification, but
we're missing that clear core specification in the first place.


Now here's a document series process question... if RFCs B & C update A,
and D is written to combine and obsolete A & B, what do you do with the
meta-data on C?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Current DNS standards, drafts & charter

[Matthew Pounsett]

On 27 March 2018 at 17:33, Paul Vixie <p...@redbarn.org> wrote:

> i see no purpose in change documents, which would add to the set of things
> a new implementer would have to know to read, and then to read.


I think we're discussing the same idea from different perspectives.

I think writing a new document that references other documents to say
"here's the sections in each of these you need to implement" without
actually making  any of them clearer is unhelpful, and just adds to the
pile of documents that an implementer needs to read.  While I recognize
there's already been one failed attempt at this, I'd still much prefer we
replace as much of that stack as possible with a smaller set of clearer
documents.



> re:
>
> Matthew Pounsett wrote:
>
>>
>>
>> On 27 March 2018 at 03:49, Ondřej Surý <ond...@isc.org
>> <mailto:ond...@isc.org>> wrote:
>>
>>
>> Again, from experience from dnsext, I would strongly suggest that
>> any work in this area is split into CHANGE documents and REWRITE
>> documents, with strict scope. Documents rewriting existing RFCs
>> while adding more stuff at the same time tend to not reach the
>> finish line.
>>
>> Does this include combining documents?  For example, it would probably
>> make sense to combine some of the clarifications documents into any
>> rewrite of 1034/1035.
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
> --
> P Vixie
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Current DNS standards, drafts & charter

[Matthew Pounsett]

On 27 March 2018 at 03:49, Ondřej Surý  wrote:

>
> Again, from experience from dnsext, I would strongly suggest that any work
> in this area is split into CHANGE documents and REWRITE documents, with
> strict scope. Documents rewriting existing RFCs while adding more stuff at
> the same time tend to not reach the finish line.
>
> Does this include combining documents?  For example, it would probably
make sense to combine some of the clarifications documents into any rewrite
of 1034/1035.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Matthew Pounsett]

On 24 March 2018 at 09:48, Joe Abley  wrote:

> But I think brushing the grains RRType parsing dust off the
> camel is not going to do much for its posture.
>
> +1

Speaking from experience, having spent a few dozen hours so far on some
client code, the code necessary to implement an additional RRType is
trivial by comparison to literally anything else in the protocol, including
such (supposedly) trivial operations as reading and writing zone files.
I've got nothing against deprecating RRTypes that we know aren't in use,
but it doesn't seem like a particularly high priority.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS Camel Viewer

[Matthew Pounsett]

On 24 March 2018 at 12:56, Matthew Pounsett <m...@conundrum.com> wrote:

> I'd suggest you should also filter out ops documents like RFC6781, since
> those serve to clear up the complexity rather than contribute to it.  I'll
> send a pull request in a bit with the ones I've spotted.
>
>
I went to go dig into this and in the process of producing a list I found
that the list was longer than I imagined, and that there are more
categories of documents that don't contribute to the camel than I thought.
 Rather than immediately send a pull request I've decided to share my
attempt at categorizing of non-camel documents here to invite discussion on
whether they should be included in the camel list, or not, and to allow for
others to spot things I've either mis-categorized or missed.

My main criteria for putting something on one of these lists is that
implementers not be in the intended audience for the document.  That is, if
the document doesn't directly contribute to a decision about whether or how
to write code, it should appear here.

There's an additional category that I didn't dig into that actually
contributes negatively to the camel: deprecations (e.g. RFC 6563).

Operational Guides
rfc1033
rfc1713
rfc1912
rfc2100
rfc2182
rfc3258
rfc4339
rfc4367
rfc4472
rfc4955
rfc5358
rfc6781
rfc7534
rfc7535
rfc7583
rfc7706
rfc7793

Proposals
rfc1535

Essays and Comments
rfc1178
rfc1591
rfc2826
rfc3071
rfc3467
rfc6305

Correspondence between parties (?)
rfc1401

Summaries of Discussions and other "Current Status" documents
rfc2825
rfc3130
rfc7085
rfc7626

Requirements Documents and Problem Statements
rfc4892
rfc4986
rfc5507
rfc6168
rfc6761
rfc8244

Procedural and Policy Documents (for IANA & other non-operations groups)
rfc6335
rfc6841
rfc6895
rfc6912
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS Camel Viewer

[Matthew Pounsett]

On 24 March 2018 at 12:51, bert hubert  wrote:

> Hi everyone,
>
> [tl;dr, check out https://powerdns.org/dns-camel/ ]
>
> As a first step in attempting to not only whine about a glut of DNS
> standards, I've made an easy to update viewer of all DNS relevant
> standards.
>
> The good news is, if we filter out obsoleted, historical, informational and
> BCP documents, we are left with a lot less pages. The bad news is, 1403
> pages remain.
>

I'd suggest you should also filter out ops documents like RFC6781, since
those serve to clear up the complexity rather than contribute to it.  I'll
send a pull request in a bit with the ones I've spotted.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-spacek-edns-camel-diet-00.txt

[Matthew Pounsett]

On 21 March 2018 at 11:58, Petr Špaček  wrote:

> Hello dnsop,
>
> draft-spacek-edns-camel-diet-00 is a new draft which partially reacts to
> The Camel talk from yesterday, and is based on plan of open-source DNS
> software vendors to get rid of EDNS workarounds.


Congratulations on an extremely short, to the point draft.  I think that's
the shortest I've ever read.
I have only one English syntax nit:  I believe "RFC 1035 non-compliant" is
the preferred form (in the Introduction).
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Terminology question: split DNS

[Matthew Pounsett]

On 20 March 2018 at 11:10, Ted Lemon  wrote:

> On Mar 20, 2018, at 3:05 PM, Matt Larson  wrote:
>
> +1 to "split DNS", which has always been the term I've used and heard. I
> completely agree that "split horizon" muddies the water by referring to a
> routing concept that probably pre-dates widespread use of split DNS.
>
>
> The term "split horizon" was common at one time, and I think we need to
> say what it means in this context.   I think it makes sense to point out
> that it is not the currently preferred term, and that people shouldn't use
> it anymore, but it's useful to clue people in as to what it means.
>
> +1.  I've heard split-horizon and views used more than just "split DNS" in
my career to refer to answering differently based on source address,
destination address (where the server has more than one), and/or
authentication (TSIG, SIG(0)).  It makes sense that split-horizon should be
noted as not being the preferred term, but it should be there since it does
get used to describe the same thing.

I think I've seen in other places in this thread an implication that we
should incorporate broader uses of providing alternate responses, and I
don't agree with that.  GSLB, geolocation, and other types of alternate
responses may be cousins to views, but they have their own definitions.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-bootstrap-validator-00.txt

[Matthew Pounsett]

On 19 March 2018 at 11:14, Joe Abley  wrote:

> Dave and I imagine this kind of thinking might be relevant and timely. Tim
> and Suz have kindly tolerated my increasingly frantic handwaving on this
> subject and have offered me some minutes in the dnsop meeting tomorrow,
> where I intend to suggest that a specification along these lines is
> necessary and that the working group should take this on.
>
> I won't be in the correct country top attend tomorrow's meeting, so I'll
state here that I think this is useful work.

I've done a quick perusal of the document and so far I've got one
question:   do you really mean to use the word "stub" in the definition of
"Validator"?  The way you're using Validator in the document, it doesn't
seem to me that it's actually limited to stub resolvers, and should include
all validating resolvers.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis

[Matthew Pounsett]

On 19 March 2018 at 08:21, Matthijs Mekking  wrote:

> I and some others have been using the term 'Negative response' to indicate
> that the response does not contain any records in the Answer section.
> Current definition seems to imply that this is only the case if the RCODE
> is NXDOMAIN, NOERROR, SERVFAIL or if there was a timeout (unreachable). The
> definition I have been using includes responses with other RCODEs too, for
> example FORMERR or REFUSED.


> I wonder if this is just me and my bubble or if others also a slightly
> different meaning of 'Negative response' as it is defined now. If there are
> others, is it worth spending a line or two about this here?
>

I would suggest that only NXDOMAIN and NOERROR+ANCOUNT=0 are negative
responses.   SERVFAIL, FORMERR, and REFUSED are error responses; you do not
know as a result of those responses whether the name/type tuple queried
about exists.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] the ??-- thing (was Re: I-D Action: draft-huston-kskroll-sentinel-04.txt)

[Matthew Pounsett]

On 1 February 2018 at 16:20, Andrew Sullivan  wrote:

> I am not convince that "it should not" is true, and having thought
> about this a little more it seems to me that an IANA registry should
> have been created in the first place for this sort of miserable
> in-label hack.  If it had been, we could have done something useful
> here.  And if we don't do so now, in short order we're going to be
> into the multi-level underscore-label hell that underscore labels are.
>

I recall that when I once read a sentence to the effect that, "xn-- is
defined to signal punycode, and no other label of the form ^..\-\- may
exist in the DNS," my first thought was that this was silly, and it should
simply have been defined as the first entry in a new registry.

So yes, I'll review and comment.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Terminology: "primary master"

[Matthew Pounsett]

On 23 November 2017 at 06:19, Havard Eidnes  wrote:

> Hi,
>
> draft 07 says:
>
>Primary master:  "The primary master is named in the zone's SOA MNAME
>   field and optionally by an NS RR".  (Quoted from [RFC1996],
>   Section 2.1).  [RFC2136] defines "primary master" as "Master
>   server at the root of the AXFR/IXFR dependency graph.  The primary
>   master is named in the zone's SOA MNAME field and optionally by an
>   NS RR.  There is by definition only one primary master server per
>   zone."  The idea of a primary master is only used by [RFC2136],
>   and is considered archaic in other parts of the DNS.
>
> First: the last sentence's claim that the idea of a "primary
> master" is only used by RFC 2136 is surely incorrect.  It is also
> used in RFC 1996, where the first quote is taken from.
>

I think the intent of the text is that an name is only used by the protocol
in RFC 2136.  It is referenced as a concept in RFC 1996, but not used by
the protocol.  But I agree that the text above is confusing, and if that's
the intent then it should be rewritten.


>
> Secondly: can someone please explain to me why the idea of a
> "primary master" where the zone data originates from and where
> updates are performed is considered archaic?
>

That doesn't make sense to me either.  Perhaps somebody thinks that Update
messages are no longer in use?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

[Matthew Pounsett]

On 16 November 2017 at 00:23, tjw ietf  wrote:

> All
>
> The author has rolled out a new version addressing comments from the
> meeting on Monday, and we feel it’s ready to move this along.
>
> This starts a Call for Adoption for draft-huston-kskroll-sentinel
>
>
I support adoption, and I'm willing to review.  This seems like an
incredible valuable mechanism.

In fact, I already have some comments/questions:

In the last paragraph of section 2,
"This mechanism is to be applied only by resolvers that perform DNSSEC
validation ..."
I seem to recall there was some ambiguity in the signal from RFC 8145
validators caused by some implementations that might send a signal even if
they weren't actively validating.  I think it would be worthwhile to make
this statement stronger and more explicit that an implementation should
only enable this mechanism if it is actually configured to validate, and
not simply capable of validation.

The records being queried seem to be anchored at the root. Given that a
server in state Vleg is expected to return A responses that implies that
the root zone needs to include these records, but I don't see that stated
anywhere.. perhaps I just missed it?

At the bottom of section 3, the document gives two definitions for a Vleg
response.  One seems to be a typo and should be Vold.
"A Vleg response pattern says that the nominated key is not yet trusted by
the resolver in its own right."
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

[Matthew Pounsett]

On 13 November 2017 at 11:28, Paul Vixie  wrote:

>
> ... If that were a problem, given BIND's market share, we should be
>>
> seeing widespread brokenness, but I don't think we are–none that's
>> making it from my support department to me or to our hostmaster@
>> accounts, at any rate.
>>
>
> yikes! you remind me of the guy who said on nanog a few years back that
> since he wasn't seeing spoofed-source ddos attacks any more, we should all
> stop worrying about them.
>

your lived experience can be cause for concern, but never for complacency.


I don't think that word means what you think it means.  Lack of concern for
a non-problem is not complacency.

The rest of us still see spoofed-source DDoS attacks, and they're a
frequent topic of discussion in the networking and DNS communities, so even
someone who doesn't see them on their network should still be aware that
they happen.  I have seen no similar discussion of REFUSED-generated chaos
in recursive servers.   If someone is seeing such brokenness, they haven't
brought it to dnsop@, or dns-operations@, or an OARC or NANOG meeting.  If
someone is seeing such brokenness, hopefully they'll speak up so that we
can advise the authoritative implementations to change their behaviour
again.

I use the plural there deliberately.  I referenced BIND above because that
was the implementation I was most familiar with at the time the behaviour
changed ... but it does seem to be the consensus among the authoritative
implementors that REFUSED is the correct response.  It wouldn't be the
first time that a majority of implementations settled on a behaviour that
didn't strictly follow the specification because it was necessary for good
inter-operation.Perhaps someone who was present for an implementer's
internal discussion about replacing upward referrals could comment on the
reasoning, and what (if any) collaboration occurred between the
authoritative and recursive implementations at the time.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

[Matthew Pounsett]

On 13 November 2017 at 10:55, Paul Vixie <p...@redbarn.org> wrote:

>
>
> Matthew Pounsett wrote:
>
>>
>>
>> On 13 November 2017 at 06:52, John Kristoff <j...@depaul.edu
>> <mailto:j...@depaul.edu>> wrote:
>>
>> REFUSED does not seem ideal to me either, but what if anything might
>> be
>> better is probably ripe discussion in a new draft.
>>
>> It makes perfect sense to me.  REFUSED is an indication that the querier
>> has been blocked from asking that question (or receiving the answer they
>> requested) by configuration, as distinct from a broken configuration
>> preventing them from getting that answer (SERVFAIL).
>>
>
> why is this nor a broken configuration?
>

It's my understanding that SERVFAIL indicates that the server sending the
RCODE–or in the case of a recursive response, the upstream authoritative
server–has a broken configuration.  I don't believe SERVFAIL indicates "you
followed a lame delegation."  As far as I'm aware, we don't have a clearly
defined signal for that, which is why many implementations chose to use
REFUSED in that case.


>
> ... Given that upward
>> referrals have obvious problems (There is no protocol or process to tell
>> a TLD operator "I am not authoritative for that delegation someone else
>> asked you to point at me") it seems to me that REFUSED is the only
>> obvious choice for indicating that an authoritative-only server is not
>> authoritative for anything at or below the QNAME.
>>
>
> i strongly disagree. this is not an administrative denial scenario. see,
> again:
>
>
> http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/
>
>
I haven't got the time this morning to search release notes, but I'm fairly
sure that in 2012, when you wrote that article, current versions of BIND
were already handing out REFUSED to indicate "I'm not authoritative for
that."  At the very least it began doing that not long after.   If that
were a problem, given BIND's market share, we should be seeing widespread
brokenness, but I don't think we are–none that's making it from my support
department to me or to our hostmaster@ accounts, at any rate.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost

[Matthew Pounsett]

On 12 September 2017 at 20:14, Ted Lemon  wrote:

> On Sep 12, 2017, at 11:06 PM, Mark Andrews  wrote:
>
> Oh sorry you can't use SRV with localhost to assign a port to this
> protocol THAT HAS NO DEFAULT PORT and only a NAME.  Is this what you
> REALLY want to do?
>
>
> Yes.
>
> I thought the goal was to ensure that localhost names map to loopback.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS names for local networks - not only home residental networks ...

[Matthew Pounsett]

On 5 September 2017 at 00:01, Walter H.  wrote:

>
> > The keyword above was examples which they clearly were.  Most of
> > 1.0.0.0/8 is in use today despite those examples.  The use of local
> > test were also clearly examples.  The Microsoft page above advocated
> > the use literal use of .local which is very different.
>
> and now in the IPv6 ages the same bug is done again ...
>
> 2001:db8: ...
>
> 2001:db8::/32 is reserved for documentation in RFC 3849.  As 192.0.2.0/24,
198.51.100.0/24, and 203.0.113.0/24 were in RFC 5737.

It's not a bug, it's a feature.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] fragile dnssec, was Fwd: New Version

[Matthew Pounsett]

On 16 August 2017 at 19:09, John Levine  wrote:

> In article <20170816071920.ba2c98287...@rock.dv.isc.org> you write:
> >> A colleague says "If TLDs allowed UPDATE messages to be processed most
> >> of the issues with DNSSEC would go away. At the moment we have a whole
> >> series of kludges because people are scared of signed update messages."
>
> Someone is wildly overoptimistic.
>
> The problem I run into over and over again is that I run someone's DNS
> and other services, but I am not the registrant and I am not the
> registrar, I just run the DNS.  Either I have to walk the registrant
> through the process of installing DNSSEC keys, or she has to give me
> her registrar account password, neither of which scales.  Slightly
> more automatic processing of updates for which I do not have the
> credentials will not help.
>
>
Have a look at:
<
https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/
>

It allows a registrar (or a registry in some ccTLD environments) to do
CDS/CDNSKEY without having to constantly scan their registrants' name
servers, and provides some advice on how to safely bootstrap DNSSEC using
CDS/CDNSKEY.

There's currently a registrar implementation at Gandi, enabled for the TLDs
for which they do DNSSEC (I believe it's beta, so you have to speak to
their support to find the API URI), and registry implementations at CIRA
(.ca) and APNIC (for their reverse zones).  The CZ.NIC folks have also
started building it into Fred, their open source registry software.

There are a few more changes the draft will go through before it's ready
for last call, but the API it describes should remain largely unchanged
from this point onward.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Matthew Pounsett]

On 13 August 2017 at 18:14, Peter van Dijk 
wrote:

>
> https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressive
> use-10#section-10 is not in the published RFC 8198 because 7942 (sadly)
> mandates that this section is removed before publication. I suspect this
> removal is specifically hurting OPENPGPKEY deployment today.
>
> So, if you want to know about implementation status, please click through
> from https://tools.ietf.org/html/rfc to the relevant draft.
>
> Ah, I did not realize that was mandated to be removed.  Thanks for filling
me in!
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Matthew Pounsett]

On 12 August 2017 at 04:29, Lanlan Pan  wrote:

> Hi Matthew ＆ Paul,
>
> Good question, :-)
>
> SWILD is a feature just for recusive cache optimization, only dealing with
> the wildcard subdomain issue (with no nodes below).
> DNSSEC + NSEC aggressive is security feature, with cryptographic contents
> such as KSK/ZSK/NSEC/NSEC3/NSEC5/...
>
> My assumption is: *we can give recursive server an alternative solution
> for wildcard subdomain cache issue, not need to depend on DNSSEC.*
> Authoritative server just simply add one SWILD RR, not much deploy cost.
> Recursive server can add SWILD support if it has an interest in wildcard
> subdomain cache optimization,  it is OPT-IN.
>

I confess it was a rhetorical question. All of the major implementations
already support DNSSEC.  8198 doesn't have an implementation status
section, but there's every reason to think the major implementations will
have support within a version of two.  A quick survey of a few issues
databases shows that at least Knot is already working on it.  That is a
significant head start; SWILD support without DNSSEC support can't happen
in any significant way, and SWILD support without support for 8198 doesn't
seem likely.

As for operator adoption, the incentives are all wrong for this to actually
get used.

Recursive operators already have a very low operational bar to turn on
DNSSEC and get the same benefit to their cache.  In both cases (SWILD and
DNSSEC) they rely on the authoritative operator opting in before that
benefit can be realized.

Authoritative operators may choose to use DNSSEC  because it will secure
their zone, and if recursive operators also have 8198-capable name servers
then the workload for both authoritative and recursive is reduced for all
terminal names.

With SWILD, there is no direct benefit to the authoritative operator, as
far as I can see.  Given that the only benefit to using SWILD is to the
recursive operator, what is the motivation for the authoritative operator
to add complexity to their deployment by adopting it?  Traditional
wildcards work fine for them.

To make the adoption problem worse, it appears as if SWILD is more limited
in its use than traditional wildcards.  For example, I don't see how you
could occlude an SWILD record with a more-specific domain name, as you can
with traditional wildcards.
Here's a common scenario based on the example from the draft:
   @86400  IN   SWILD  _
   _ 3600  IN   CNAME  map.bar.net.
   *  600  IN   CNAME  _
 dev  600  IN   CNAME  map.dev.bar.net.

How does SWILD behave when a client queries for dev?  According to the
draft, the authoritative server would return the SWILD record at the apex.
An SWILD-aware recursive server seems like it would ignore the CNAME
returned for dev and instead use the CNAME for _, which is not what the
operator intended.


>
> *I don't expect implementers would adopt SWILD 100% before adopting
> DNSSEC+NSEC aggressive. Just give an alternative choice, implementers can
> decide adopting or not, before or after, we won't pre-select for them.*
> Even if both Authoritative server and Recursive server support DNSSEC+NSEC
> aggressive, when will they configure default dns query with dnssec ? (for
> NSEC agreesive cached deduced wildcard)
>

We already know that a year ago 26% of all end users were behind some sort
of validating resolver, a number which continues to climb as more ISPs turn
on validation, and more users switch to things like Google Public DNS
.  This
isn't an ideal deployment status so long after DNSSEC was standardized, but
it's a long way ahead of SWILD.

You'll need to have a very compelling argument for me to believe that SWILD
is both more useful than DNSSEC and more likely to be deployed at any kind
of scale that would make a difference.  I just don't see it.

Add to that Paul's point that we would very much like to encourage DNSSEC
adoption, I don't see why we'd add support for an alternative technology
that accomplishes a subset of its features.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Matthew Pounsett]

On 11 August 2017 at 01:02, Lanlan Pan  wrote:

>
>> We can get even better behavior from aggressive NSEC use. Here are
>> advantages of aggressive NSEC use:
>> - does not require changes to existing authoritatives or signed zones
>> - less fragile (if we consider manual SWILD specification as an option)
>> - supports wildcards with nodes below it
>>
>
> Yes, aggressive NSEC use has advantages if:
> 1) AUTH give NSEC RR.
> 2) Every Intermediate Resolver supports DNSSEC validating and the NSEC
> aggressive use.
>

It sounds like you're assuming that SWILD would be supported by caching
servers that do not support DNSSEC or NSEC aggressive use.  Why do you
expect implementers would adopt SWILD before adopting these much older
features?



>
> Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that
>> is okay: New features are provided only by the latest version of
>> the protocol.
>>
> But:
> 1) many wildcards occupy the Resolver cache, with no nodes below them.
> 2) many wildcards AUTH not give NSEC RR.
> 3) many resolvers not support DNSSEC validating, not to mention NSEC
> aggressive use.
>
> On the view of new feature, SWILD can be an alternative simpler choice to
> deploy.
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf

[Matthew Pounsett]

On 3 August 2017 at 18:36, Dave Crocker  wrote:

>
>
> Therefore I propose to:
>
>1. Have this document define the simple, sole, authoritative mechanism
> for registering "top-level" (global scope) underscore names.
>
>2. Create a separate document that specifies modifications to the SRV
> and URI documents, rationalizing the use of underscore names, through the
> mechanism defined in -attrleaf-.
>
> Do I understand correctly that the intent is to obsolete existing
underscore registries (whether they be actual IANA registries, or just code
points listed in a draft) and move their data to a new, central registry?
This seems sensible to me.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Status of "let localhost be localhost"?

[Matthew Pounsett]

On 2 August 2017 at 13:24, Jacob Hoffman-Andrews  wrote:

> On 08/01/2017 06:23 PM, Mark Andrews wrote:
> > The query for foo.localhost doesn't need to hit-the-wire for this
> > to be a issue.  Ask your self why RFC 6303, Security section has
> >
> >As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
> >namespaces, the zones listed above will need to be delegated as
> >insecure delegations, or be within insecure zones.  This will
> >allow DNSSEC validation to succeed for queries in these spaces
> >despite not being answered from the delegated servers.
> >
> > or draft-ietf-homenet-dot-10 is doing the same thing for "home.arpa".
>
> RFC 6303 says "as DNSSEC is deployed within...". There's no plan to
> deploy DNSSEC within .localhost, because it doesn't make sense there;
> all resolutions should be handled locally.
>

6303 is talking about what to do with DNS zones for RFC1918 and other
local-scope address space when their global-scope parent zones are signed.
The correct rephrasing of that quote which would apply to .localhost is "as
DNSSEC is deployed within the root namespace..."  An event which is long
past.

In the case where 'localhost' is being passed to DNS resolution software, a
validating stub (for example inside a web browser) needs a way to know that
the 'localhost' TLD should be treated as insecure.  In that case, the only
way to accomplish that is with an insecure delegation at the root.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

[Matthew Pounsett]

On 22 July 2017 at 17:40, Woodworth, John R <john.woodwo...@centurylink.com>
wrote:

> > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Matthew
> Pounsett
>
> >
>
> > > On 20 July 2017 at 17:53, John R Levine <jo...@taugh.com> wrote:
>
> > > That's why I don't share the fears about BULK: you cannot easily
>
> > > deploy a new feature that will require a change in the resolvers,
>
> > > because you don't know all the resolvers, and cannot change them even
>
> > > if you know they are too old. But your secondaries are only a small
>
> > > set of carefully chosen servers, and you have your say.
>
> >
>
> > I hear otherwise from people who run big DNS farms.  It's common to
>
> > use multiple secondary providers, and it's hard to tell who's running
>
> > what server software.  I also note that it took about a decade before
>
> > people felt comfortable using DNAMEs.
>
> >
>
>
>
> Hi Matthew,
>
>
>
> Thanks for your comments.
>
>
>
> I hear and understand your concerns.  We have similar concerns but
>
> *I* feel we could offer a phased-in approach to set everyone's
>
> expectations appropriately.  If one chooses to step ahead of the phase
>
> at least they'd have an idea what troubles await them.
>

Something's wrong with your email client.  Your quoted text above was not
me.


>
>
> >
>
> > Dear $VENDOR.
>
> >
>
> > I'm a customer who is considering deploying the BULK RR type into my
>
> > zone, and I would like to know whether your systems support it.
>
> >
>
> > Thank you,
>
> > $CUSTOMER.
>
> >
>
> >
>
> > That said.. there is still an issue with key distribution for online
>
> > signing which is required to make this work.   I see the utility in
>
> > BULK, but I'm persuaded that there needs to be more work before it's
>
> > deployable in an environment where *XFR is required.
>
> >
>
>
>
> Online signing in this environment will not be possible until this
>
> is solved but I believe the phased in approach would give us the time
>
> to solve for it without delaying insecure deployment (phase1).
>
>
> What's your mechanism for enforcing (or even signalling) this phased
approach in the DNS?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

[Matthew Pounsett]

On 20 July 2017 at 17:53, John R Levine  wrote:

> That's why I don't share the fears about BULK: you cannot easily
>> deploy a new feature that will require a change in the resolvers,
>> because you don't know all the resolvers, and cannot change them even
>> if you know they are too old. But your secondaries are only a small
>> set of carefully chosen servers, and you have your say.
>>
>
> I hear otherwise from people who run big DNS farms.  It's common to use
> multiple secondary providers, and it's hard to tell who's running what
> server software.  I also note that it took about a decade before people
> felt comfortable using DNAMEs.
>

Dear $VENDOR.

I'm a customer who is considering deploying the BULK RR type into my zone,
and I would like to know whether your systems support it.

Thank you,
$CUSTOMER.


That said.. there is still an issue with key distribution for online
signing which is required to make this work.   I see the utility in BULK,
but I'm persuaded that there needs to be more work before it's deployable
in an environment where *XFR is required.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-01.txt

[Matthew Pounsett]

On 11 April 2017 at 15:27, Carl Clements  wrote:

>
> There is one detail that I feel is not explicit enough in 6781 that is
> extremely relevant during a DNSSEC operator migration. It is assumed in
> this document that DNSKEY_*_A and DNSKEY_*_B use the same signature
> algorithm. That assumption is derived from the implication that this
> document describes a Double-DS KSK rollover, which is incompatible with
> an algorithm rollover even with the liberal approach to Section 2.2 of
> RFC 4035 . I think it
> would be helpful to at least reference this implication in section 2.1 of
> your draft.
>

This is an excellent point, and I'll add that to the doc ... likely in the
assumptions for now.  More below.


>
> My other thought is regarding the instruction to pre-publish DNSKEY_K_B
> and post publish DNSKEY_K_A. As far as I can tell, and we have discussed
> this a little out of band, the only value provided by publishing and
> signing this KSK is to satisfy any over-conservative DS checks performed by
> the maintainers of the parent zone. The essential chain of trust "cross
> pollination" is that both DNSKEY_Z_A and DNSKEY_Z_B are signed by the
> either KSK.
>

Yeah, the procedure as described in the doc currently is a little
over-cautious with key handling.  It's mainly to simplify the description
of requirements, but I'm planning to change the way it's written out.

One piece of feedback I've received privately is that the document could
benefit from having the *requirements* for a clean transfer spelled out,
and that the procedure be included as an example, possibly of the shortest
path to meet the requirements.  I think that bit of reorganization would
help with the explanation of when it's actually important to
pre/post-publish keys, and coincidentally provide a good place for your
note about algo compatibility to live.

I've been working on text, but it's been a busy few months so I'm not quite
ready to roll -03.


> Lastly, it looks as though you opted to spell out TTL waits, for example.
> For what is it worth, I am in favour of this choice.
>
> I added that in -02 with the long-form description of the procedure.
Given that the intended audience is not intended to be able to work out
this procedure on their own, I thought it was important to be as explicit
as possible.

Thanks for the feedback!
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New terminology for root name service

[Matthew Pounsett]

On 15 March 2017 at 13:31, Paul Hoffman  wrote:

> Greetings again. RSSAC has published a lexicon of terms that are commonly
> used with respect to the root of the public DNS, but are not in RFC 7719. I
> have opened an issue for the terminology-bis document at
> https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/17 and
> would be intereted to hear what people think about including those terms in
> our document.
>
>
Hi Paul.  Noting there hasn't been any actual feedback on your question ...
I think the -bis document should at least reference RSAAC026, but I think
importing those terms (particularly the ones that are not root-specific:
instance, publish, serve) would be useful.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New draft for ALIAS/ANAME type

[Matthew Pounsett]

On 4 April 2017 at 13:21, Tony Finch  wrote:

> > I believe that's a faulty assumption.   Here's some data:
> >
> > [...] During the month of February, [...] an average of 31 changes per
> zone. [...]
>
> That seems to agree with what I meant, though I probably should have said
> "per-zone" somewhere :-)
>
> That's the average, but there's a not-insignificant number there being
updated many times per day.Most of the time, you're right, there are
few changes, but one can't assume that any given alias will have a low rate
of change.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New draft for ALIAS/ANAME type

[Matthew Pounsett]

On 3 April 2017 at 07:55, Tony Finch  wrote:

>
> If you expand ALIAS on the master server like this, I would expect that
> most of the time the target addresses won't change very frequently, so the
> IXFR rate should be much less than the ALIAS polling frequency.
>

I believe that's a faulty assumption.   Here's some data:

One of our registrars has ~3.6 million zones hosted on its name servers.
We have historically allowed end users to put CNAMEs wherever they want in
the UI, but have a CNAME "emulator" in the publishing path replaces the
illegal ones before they're inserted in a zone.

During the month of February, the CNAME emulator initiated 872k changes to
28k zones, with an average of 31 changes per zone.  The minimum/maximum
changes per zone were 1 and 231 respectively.

A change is updating one or more replaced CNAME records in a single action,
so this doesn't count individual CNAMEs updated.  It's also possible actual
changes occurred on authoritative servers more often, since we avoid DoSing
upsteam authoritatives.

Here's the distribution of the  number of zones per number of changes.
I've used a LOG scale, since there's a spike of 10k zones with 42 changes,
which makes a linear graph unreadable.


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

Re: [DNSOP] .arpa

[Matthew Pounsett]

On 23 March 2017 at 13:50, Ray Bellis  wrote:

>
>
> Hence w.r.t Matt Pounsett's argument that the -redact document go first
> and then the assignment of ".homenet" be done later, the Homenet WG has
> argued *very* strongly that this is not acceptable because it leaves
> HNCP in an indeterminate state.
>
> On the other hand, as Ralph Droms points out, not going ahead with either
leaves .home in an indeterminate state.  And, going ahead with both in the
absence of an answer on the homenet. insecure delegation (assume a
hypothetical third hand) leaves the whole thing undeployable in the
presence of any validation between the local nameserver authoritative for
.homenet and and-user applications.  Validating applicatinos, stubs,
localhost resolvers, and forwarders all break HNCP, unless I've completely
misunderstood something.

Since we're trying to encourage validation as close to the application as
possible, I would think we'd avoid attempting to deploy things that cannot
work with application-level validation.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Matthew Pounsett]

On 19 March 2017 at 21:44, Suzanne Woolf  wrote:

> This document is the product of the homenet WG, which has asked the IESG
> to approve it for publication, so our comments are strictly advisory to the
> IESG. There was some discussion of the draft on this list shortly after it
> appeared, in November 2016, but it’s always the AD’s prerogative to ask for
> additional review.
>
>
To first answer the two questions in the call for reviews:  I see no
technical problems either with the RFC6761 application in the draft, or
with having an unsecured delegation in the root zone, should 'homenet.' be
chosen to anchor HNCP names.   There's a clear technical need for special
handling at the border between the local network and the Internet (local
names) and–in the absence of a specification for getting local trust
anchors into every validating resolver inside the local network–an
unsecured delegation for whatever name is chosen to facilitate end-to-end
security.

The reason we have a problem here is that this has been gone about in
entirely the wrong order, and procedurally leaves the IETF in a difficult
position.  We have no business demanding a root zone delegation from ICANN,
and publishing an RFC that requires that to happen in order to be useful is
tantamount to making that demand, regardless of how nicely the demand is
worded.

The need to correct the mistakes of the HNCP draft has, I think, resulted
in a rush that has been detrimental to careful consideration.  At the risk
of repeating the obvious, so that I can refer back to this list, what
should have been done is:
1) speak to ICANN (the community) about whether/how it's possible for IETF
to reserve & delegate an unsecured name from the root
2) if the community says yes, and after a process is defined, pick a name
that doesn't conflict with anything (including DITL research)
3) write the draft to reserve the name

While I appreciate that there's some risk this name might be exposed to end
users, and that perhaps some tiny percentage of end users might react badly
to seeing a reference to ARPA, I think that exposure is mostly going to
happen with technology professionals and hobbyists (power users), not the
typical home user.  So while it still may be preferable to use homenet.
over homenet.arpa., I'm unconvinced that it *needs* to be that way.

If HOMENET is set on trying for homenet., then I would recommend proceeding
with draft-ietf-homenet-redact, and shelving this draft until (1) and (2)
can be completed.

If there's a need that draft-ietf-homenet-dot be finalized before (1) and
(2) can happen, then homenet. should be replaced with homenet.arpa..

- Matt


PS: given that there is already talk of lawsuits over home. and corp., and
given that for any name that might be chosen there's likely somebody out
there in the world that thinks that name might be valuable to register, I
think the chances of getting a 'yes' out of the ICANN community is very
nearly zero.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[Matthew Pounsett]

On 21 December 2016 at 12:47, Ted Lemon <mel...@fugue.com> wrote:

> On Dec 21, 2016, at 12:39 PM, Matthew Pounsett <m...@conundrum.com> wrote:
>
> None of those things are required by RPZ, but I believe they are required
> by the hypothetical better alternative that a few people have suggested we
> should work on instead.
>
>
> To be clear, there is no real alternative to RPZ in terms of providing
> protection.   We could provide annotation in RPZ, and that might be useful
> in some cases.   But ultimately if a domain is malicious, you _have_ to
> block it by not providing an answer.   If you do not, only those devices
> that implement the new protocol will be protected, which is to say we will
> be failing broken, not failing safe.
>

You and I are in energetic agreement.


>
> If you want the browser to receive and understand a signal then that
> signal needs to be invented, the DNS servers need to be modified to send
> it, and the browsers (and all other applications you want to benefit) need
> to be modified to receive and understand it.  This is the point I was
> making.
>
>
> Yes, correct.   I proposed a draft in tls to do this after the redirect
> has happened, which I think is useful, but does not solve the problem of
> signaling when DNSSEC is available: https://tools.ietf.
> org/html/draft-lemon-tls-blocking-alert-00
>
> If we wanted to account for DNSSEC and provide signaling, I think the
> signaling would have to take the form of a signed EDNS0 option that
> signaled similar information.
>
> In the draft I’m referencing, it was my intention to provide a set of
> values that could be returned to indicate what has happened.   I think it’s
> a bad idea to provide anything more than that, because for example if you
> return a text string, that becomes an attack surface.   You can use it to
> trick the user into bypassing their security settings.
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[Matthew Pounsett]

On 21 December 2016 at 12:29, Ted Lemon  wrote:

> Practically speaking, none of these changes are _required_.   The worse
> case scenario is that if someone looks up a malicious domain, you get back
> a bogus answer that doesn’t validate.   The resolver reports "no answer"
> because an answer that doesn’t validate is no answer.   The user sees that
> the page fails to load.   There is little they can do to bypass this, and
> they aren’t likely to have a sense of how to do it, so our job is pretty
> much done.
>

None of those things are required by RPZ, but I believe they are required
by the hypothetical better alternative that a few people have suggested we
should work on instead.


>
> It would be _nice_ if the browser, for example, could get some kind of
> positive, signed assertion that some authority has claimed that the domain
> in question is malicious (or whatever).   This would be good mostly for the
> purpose of transparency, so it’s not clear that it makes any difference if
> it’s communicated to the user: people who care about transparency will be
> able to look it up, and, in particular, people who are interested in
> watching for censorship will have no problem at all noticing that it is
> happening.
>

If you want the browser to receive and understand a signal then that signal
needs to be invented, the DNS servers need to be modified to send it, and
the browsers (and all other applications you want to benefit) need to be
modified to receive and understand it.  This is the point I was making.

RPZ is not the ideal, but it works, and goes beyond being deployable–it is
deployed.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[Matthew Pounsett]

On 21 December 2016 at 10:53, Paul Wouters  wrote:

>
> And 1) should not need to break DNSSEC. IETF should come up with a
> better solution for signaling a DNS lookup might be unhealthy for
> the enduser.
>
> Other than returning an altered answer (pointing to an informational site)
or no answer at all, what would this look like in practice?

The signal probably needs to be in-band in the DNS response, and downstream
recursive/forwarding servers need to know to pass those data along with
certain responses. So there's a change to the protocol.

Libraries (glibc, etc.) need to be modified to receive and understand these
new data and pass them on as part of a gethostbyname() call, so there's a
change to all operating systems.

Applications that use the DNS need to understand this new signal and know
what to do with it, so there's a change to every application that uses the
DNS.

These are the things you need in place for an alternative to be effective.
I think that would be a fantastic way for things to work, but we haven't
even managed to get a majority of applications to implement DNSSEC yet.

If you think the above sounds silly, then please propose some other
alternative with a shorter path to deployment.  Taking it out of band of
the DNS probably makes things simpler, but then you still need to modify
every recursive server and every application.  In the intervening decades
while that is being designed and deployed, operators are going to continue
using RPZ or something like it, so why don't we document that, and how it
should work?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[Matthew Pounsett]

On 20 December 2016 at 10:37, Jim Reid  wrote:

>
> > On 20 Dec 2016, at 15:29, Ray Bellis  wrote:
> >
> > On 20/12/2016 15:16, tjw ietf wrote:
> >
> >> This starts a Call for Adoption for draft-vixie-dns-rpz
> >>
> >> Please review this draft to see if you think it is suitable for adoption
> >> by DNSOP, and comments to the list, clearly stating your view.
> >
> > Yes, it's suitable, as an informational document describing current
> > implementations.
>
> +1
>
> Agreed.  I think it will be useful to have this documented.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-cheshire-sudn-ipv4only-dot-arpa-06

[Matthew Pounsett]

On 28 November 2016 at 15:24, Mark Andrews  wrote:

>
> In message 

[DNSOP] Review of draft-cheshire-sudn-ipv4only-dot-arpa-06

[Matthew Pounsett]

I think this draft is useful and necessary, and that the registration of
ipv4only.arpa within the SUDN registry is justified by the applicability
statement of RFC 6761.  Having NAT64-unaware recursive servers answer
authoritatively as they would for other reserved names (e.g. RFC 1918
address reverse lookups) is a useful optimization, and having NAT64-aware
servers answer without querying the arpa servers removes a problematic
external dependency.  Furthermore, the inclusion of example.{org,com,net}
in RFC 6761, which are clearly less special in their technical handling
than ipv4only.arpa, provides further justification for ipv4only.arpa's
inclusion in the registry.

I have one comment and one question on the specifics of the reservations
considerations sections:

The answers to question 5 for both reservation considerations sections seem
to mix developer and operational considerations for authoritative servers.
It's my understanding that operational considerations should be handled
under question 6 .. and in both cases they mostly are.   Removing the
duplicate instructions, and moving the remaining operational notes to
question 6 would simplify the text.  I'm happy to provide suggested text if
that's useful to the authors.


Have the authors considered including RFC2119 language in the answers to
question 6 directing the operators of the arpa and in-addr.arpa zones to
configure their name servers to answer for these special names?  e.g.
"Operators of the arpa zone MUST configure their servers to answer for
ipv4only.arpa as defined in RFC7050." .. and a similar statement for the
reverse lookups.

Although I lean slightly in favour of including such text, I don't have a
strong opinion either way.  The draft indicates an expectation that the
operators of arpa and in-addr.arpa will configure their servers as
requested, but for completeness and strict conformance to 6761 it might be
useful to be more explicit.  On the other hand, the IAB statement in 7050 §
8.3 could be read to be that directive.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Heads-up - draft about "letting localhost be localhost" in SUNSET4 that really should be in DNSOP

[Matthew Pounsett]

On 17 November 2016 at 12:00, Dan York  wrote:

> DNSOP,
>
> In SUNSET4 right now, Emily Stark from Google presented a draft from Mike
> West (also Google) asking to update the language in RFC 6761 around the
> resolution of localhost:
>
> Draft: https://tools.ietf.org/html/draft-west-let-localhost-
> be-localhost-02
>
> Slides: https://www.ietf.org/archive/id/draft-west-let-
> localhost-be-localhost-02.txt
>
> It was brought to SUNSET4 because they are interested in stopping the
> proliferation of IPv4 addresses.
>

This sounds like something we should consider adopting in DNSOP.


>
> Dan
>
> --
> Dan York
> Senior Content Strategist, Internet Society
> y...@isoc.org   +1-802-735-1624
> Jabber: y...@jabber.isoc.org
> Skype: danyork   http://twitter.com/danyork
>
> http://www.internetsociety.org/
>
>
>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSSEC operational issues long term

[Matthew Pounsett]

On 17 November 2016 at 06:57, joel jaeggli  wrote:

>
> A decade is well within the service range of all sorts embedded systems.
>


Service range, sure.  But back-room storage range?  I agree it's an
unreasonably long time to have something to sit on a shelf, never-used, and
then expect it to work when powered on.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-dickinson-dnsop-dns-capture-format

[Matthew Pounsett]

On 15 November 2016 at 17:09, tjw ietf  wrote:

> All
>
> The response from the room today was pretty positive this draft was worth
> adopting and pursuing.  We felt their was little benefit in waiting to
> begin this Call for Adoption.
>
> This starts a Call for Adoption for  draft-dickinson-dnsop-dns-
> capture-format
>
> The draft is available here:
>
> https://datatracker.ietf.org/doc/draft-dickinson-dnsop-dns-capture-format/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 1 December 2016.
>
>
I support the adoption of this draft.


> Thanks,
> tim wicinski
> DNSOP co-chair
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-02.txt

[Matthew Pounsett]

On 9 November 2016 at 09:03, Antoin Verschuren  wrote:

> Hi Matt,
>
> I cannot help noticing that draft-pounsett-transferring-automated-dnssec-zones
> is providing the same solution as an earlier draft draft-koch-dnsop-dnssec-
> operator-change.
> This draft has already gone through a review process, and is considered to
> be done content wise by the authors.
>
> The reason why draft-koch-dnsop-dnssec-operator-change has never made it
> to WG adoption in DNSOPS is because of IPR that is now also targeting your
> draft.
> There is currently discussion on this IPR on the REGEXT mailinglist
> because draft-ietf-eppext-keyrelay, which is the standardization of the
> provisioning parameters for this secure operator change concept is stalled
> for a long time as well because of this IPR.
>
> Can I ask you how your draft is different from 
> draft-koch-dnsop-dnssec-operator-change
> to justify a new attempt?
> Wouldn’t the IPR pose the same adoption issues as draft-koch-dnsop-dnssec-
> operator-change?
>

I don't actually see the overlap.  Although perhaps I'm just missing
something.

Suzanne pointed draft-koch-dnsop-dnssec-operator-change out to me right
after my talk at the OARC meeting last month.. my first quick scan of it
and my more recent (this morning) closer look suggest to me that it is
dealing with the problem of moving a signed zones between non-cooperating
registrars.   One of the assumptions of the documented procedure is that
the DNS operators are not sharing DNS zone data, for example.

draft-pounsett-transferring-automated-dnssec-zones's basic assumptions are
that the DNS operators are cooperating, and that the principle requirement
for using the procedure is that they must publish the same zone throughout
the procedure, which implies an active zone transfer (or an analogue) at
every stage.

It seems to be that these two drafts are attempting to solve different
problems.


>
> The authors of draft-koch-dnsop-dnssec-operator-change are willing to
> revive the draft and ask for WG adoption by DNSOPS as well.
> As co-author of that draft and the original inventor of the secure
> dns-operator change method, I’m open to see how that draft can be improved
> by your attempt, and see if we could work together to get this concept
> described in an Informational RFC.
>

I'll defer on answering this until we resolve whether the documents
actually overlap. :)If they do I have no problem dropping my draft and
contributing to draft-koch-dnsop-dnssec-operator-change instead.. but if
they are actually solving unrelated problems then I'm not sure I see the
value in a merge.


>
> draft-ietf-eppext-keyrelay is stalled in IESG review for 328 days now, and
> I wouldn’t want the DNSOPS WG to waste the same time while the IPR issue is
> not resolved.
> Instead, I think it would be wise to jointly address both the
> Informational concept description and provisioning solution and if members
> of DNSOPS have any input to the IPR discussion on the REGEXT mailinglist, I
> would invite them to contribute.
>

I'm brand new to the IPR issue, so these comments probably aren't well
thought out.  I noted when the IPR claim first appeared on my draft that
the same patent application is used in a claim against RFC6781.  I had
thought that the RFC had gone ahead despite the claim, and therefore it
wouldn't be a big problem for my draft, but having a closer look makes me
think that IPR claim may have appeared after publication.

I've seen the discussion in REGEXT and the comments from Scott about the
holdup in attaching a licensing intention to the IPR claims.  It seems to
me that it shouldn't be hard for Verisign to declare their intention should
their patent(s) be awarded.  If they aren't awarded then those licensing
intentions become irrelevant, and if they are awarded then.. well.. we know
in advance what Verisign's intentions are.   I don't understand why this is
a problem, but I Am Not A (Patent) Lawyer.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-02.txt

[Matthew Pounsett]

On 3 November 2016 at 08:59, Bob Harold  wrote:

>
>
> 2.4.  The Procedure
> Second paragraph under "Signing Migration",
> "ganinig" -> "gaining"
>
> In "Post Migration"
> "severs" is correct, but it looks so much like a common misspelling of
> "server" that I would replace it with "stops" or "breaks".
>
> Thanks.  I've fixed both of those in the document.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] FYI - Added note about ECDSA resolver issue in Sweden - Fwd: New Version Notification for draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt

[Matthew Pounsett]

On 31 October 2016 at 00:22, George Michaelson  wrote:

> It is only my personal opinion, but I believe registrars are incorrect
> in performing crypto alg checks on proffered DS, and this is an
> entirely unwarranted, and incorrect understanding of their role. It
> conflates one public good (checking) with another public good
> (registry of data into the DNS) and assumes one out-ranks the other:
> It doesn't, and the inability to track crypto alg change, makes the
> checking wrong. Its the lesser of two evils to stop checking, and
> permit unknown algorithms through.
>
> I think this needs to be flagged up. Either they should be told to
> stop, or the requirements for algorithm agility which their role
> places on them should be made explicit.
>

I know of a couple of cases where registries perform similar checking.
Depending on the implementation, the registrar may need to perform the
checks themselves in order to prevent future upstream calls from generating
errors.

I think the way I'd implement this is to perform "best effort" checking.
If I know the algorithm, then make sure that the DS/DNSKEY supplied is
correct for that algorithm.  If I don't know the algorithm, pass it through
as-is (and log it so that I can have my developers investigate and add that
algo to the check library).
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-02.txt

[Matthew Pounsett]

Hi all.

I've submitted an update for the below draft which I'd like the working
group to eventually consider for adoption.  If there's time in the agenda,
I'd like to ask the chairs for some time to discuss this in Seoul.

As with the previous version, I'm looking for some specific feedback on a
few things.

1) I believe this draft represents operational experience that could be
added to RFC6781.  While it doesn't (intentionally) change anything in
6781, I think the additional operator change procedure justifies the
"updates" meta-data in the draft.  With the increase in gTLDs and the
expected future increase in gTLD transfers I think it's important to put
this information in front of operators searching for advice, which makes
having it appear as a link from the 6781 meta-data important.  I'd like to
get the group's feeling on that.

2) RFC 6781 does not explicitly describe the timings of each step in the
operator change procedure, leaving that as an exercise for the reader to
obtain by reading earlier sections of the RFC.  The -01 version of this
draft followed that style for a couple of reasons: first, so as not to
unnecessarily duplicate any information; second, to avoid unintentionally
introducing any ambiguity or update to the information in 6781.  I've been
of two minds on that, however.  I felt that the aim of this draft–to
provide advice to inexperienced operators–was not well served by leaving a
prose description of the procedure out.  With the recent publication of
errata for § 4.1.2, my opinion has tipped slightly the other way, and so
I've added text to describe the steps and their timings.

3) I don't believe this draft raises any *new* security considerations, so
I've done my best to incorporate by reference the security considerations
from 6781.  I'd like to know your thoughts on this as well.


-- Forwarded message --
From: <internet-dra...@ietf.org>
Date: 30 October 2016 at 23:29
Subject: New Version Notification for
draft-pounsett-transferring-automated-dnssec-zones-02.txt
To: Matthew Pounsett <m...@conundrum.com>



A new version of I-D, draft-pounsett-transferring-
automated-dnssec-zones-02.txt
has been successfully submitted by Matthew Pounsett and posted to the
IETF repository.

Name:   draft-pounsett-transferring-automated-dnssec-zones
Revision:   02
Title:  Change of Operator Procedures for Automatically Published
DNSSEC Zones
Document date:  2016-10-31
Group:  Individual Submission
Pages:  7
URL:https://www.ietf.org/internet-drafts/draft-pounsett-
transferring-automated-dnssec-zones-02.txt
Status: https://datatracker.ietf.org/doc/draft-pounsett-
transferring-automated-dnssec-zones/
Htmlized:   https://tools.ietf.org/html/draft-pounsett-transferring-
automated-dnssec-zones-02
Diff:   https://www.ietf.org/rfcdiff?url2=draft-pounsett-
transferring-automated-dnssec-zones-02

Abstract:
   Section 4.3.5.1 of [RFC6781] "DNSSEC Operational Practices, version
   2" describes a procedure for transitioning a DNSSEC signed zone from
   one (cooperative) operator to another.  The procedure works well in
   many situations, but makes the assumption that it is feasible for the
   two operators to simultaneously publish slightly different versions
   of the zone being transferred.  In some cases, such as with TLD
   registries, operational considerations require both operators to
   publish identical versions of the zone for the duration of the
   transition.  This document describes a modified transition procedure
   which can be used in these cases.




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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[Matthew Pounsett]

Following Suzanne's request to send text, I've put together a first draft
of what I think the Remediating (renamed to Remediation) section should
look like.  In addition to this rewrite, I'd recommend moving it to be
directly after the Testing section.


# Remediation

Name server operators are generally expected to test their own
infrastructure
for compliance to standards. The above tests should be run when new systems
are brought online, and should be repeated periodically to ensure continued
interoperability.

Domain registrants who do not maintain their own DNS infrastructure are
entitled to a DNS service that conforms to standards and interoperates well.
Registrants who become aware that their DNS operator does not have a well
maintained or compliant infrastructure should insist that their service
provider correct issues, and switch providers if they do not.

In the event that an operator experiences problems due to the behaviour of
name servers outside their control, the above tests will help in narrowing
down the precise issue(s) which can then be reported to the relevant party.

If contact information for the operator of a misbehaving name server is not
already known, the following methods of communication could be considered:

- the RNAME of the zone authoritative for the name of the misbehaving server
- the RNAME of zones for which the offending server is authoritative
- administrative or technical contacts listed in the registration
information
  for the parent domain of the name of the misbehaving server, or for zones
  for which the name server is authoritative
- the registrar or registry for such zones
- DNS-specific operational fora (e.g. mailing lists)

Operators of parent zones may wish to regularly test the authoritative name
servers of their child zones.  However, parent operators can have widely
varying capabilities in terms of notification or remediation depending on
whether they have a direct relationship with the child operator.  Many TLD
registries, for example, cannot directly contact their registrants and may
instead need to communicate through the relevant registrar.  In such cases
it
may be most efficient for registrars to take on the responsibility for
testing
the name servers of their registrants, since they have a direct
relationship.

When notification is not effective at correcting problems with a misbehaving
name server, parent operators can choose to remove NS records that refer to
the faulty server.  This should only be done as a last resort and with due
consideration, as removal of a delegation can have unanticipated side
effects.
For example, other parts of the DNS tree may depend on names below the
removed
zone cut, and the parent operator may find themselves responsible for
causing
new DNS failures to occur.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[Matthew Pounsett]

On 16 October 2016 at 21:15, Mark Andrews  wrote:

>
> In message 

Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[Matthew Pounsett]

On 9 October 2016 at 21:32, Mark Andrews <ma...@isc.org> wrote:

>
> In message <CAAiTEH9Rbw4u3gV9GULQ-8WdoPHf3SXQMTRY+CtfUGrNQSGAWw@
> mail.gmail.com>, Matthew Pounsett writes:
> >
> > My first impression of this document is that it is still in need of some
> > extreme editing – mostly for grammar and syntax, but also for clarity and
> > readability.  I've included many of the early problems I found in a list
> > of nits at the end of this email, but at two and three errors per
> paragraph
> > (and occasionally per sentence) it's just too much to cover this way, so
> I
> > stopped noting nits after the first couple of sections.  I suggest such
> > sweeping changes to later sections that any nits I noted there may end up
> > being rewritten anyway.
> >
> > The draft still suffers from inconsistent approaches to the content.  In
> > any given section it might shift from a problem description, to
> > admonishment, to advice for workarounds, and back again without a clear
> or
> > consistent structure.  This makes it difficult to figure out what the
> > intended takeaway is in places.  I've tried to point out specifics below,
> > and suggest better approaches where I can.
> >
> > Don't let my criticism of the document give you the wrong impression.  I
> > think this is useful work, and I'm very appreciative of the work that has
> > gone into it so far.  I just happen to think that there is still work
> left
> > to be done.
> >
> >
> > As for the meat of the matter...
> >
> >
> > In the Introduction, in the paragraph which begins "Unless a nameserver
> is
> > under attack" would it make sense to replace "broken delegations" with
> > "lame delegations"?   We have a term for delegating to a name server
> which
> > is not authoritative for the delegation... we should probably use it.
>
>
>
> > Section 2, "Consequences," seems out of place to me.  It makes a number
> of
> > assertions that seem to follow no particular flow, or pattern.  The line
> > of
> > reasoning or evidence that lead to these assertions has not appeared yet
> > in
> > the document, and so they seem unsupported.  If I'm interpreting the
> > author's intent correctly, perhaps this section should be split up and
> > interspersed into the current section 3 as the direct or indirect
> > consequences of each type of dropped response.
> >
> >
> > The way section 3 is titled and introduced I expect to just see a survey
> > of
> > commonly dropped queries, but the content seems to be inconsistent as to
> > whether it's just a survey, or a survey and advice to client authors
> about
> > working around problems, or just advice without a clear description of
> the
> > problem behaviour.  It seems to me that if the section is intended to be
> > advice to authors, then it should be introduced that way.  Also,
> > clarification for server authors on how they should respond–instead of
> > dropping queries–should probably come before any advice on how to work
> > around dropped queries.
> >
> > If the goal here is to help implementors fix what's broken, then I would
> > suggest each subsection start with a clear description of an observed
> > broken behaviour, followed up with a description of how that behaviour
> > should change (possibly only as a short summary with external references,
> > as we don't want to reproduce whole RFCs here) and then follow that with
> > advice for client authors for working around existing brokenness.
> > Sticking
> > to a pattern–either the one I've suggested or some other–for every query
> > type would make the entire section easier to read.  It will also make it
> > easier for the working group to go through the section item by item and
> > discuss whether we agree on the problem descriptions and proposed
> > remediation.
> >
> > RFC 2119 language is conspicuously absent from this section and SHOULD be
> > added.
> >
> >
> > Section 4, "Remediating", is very problematic.  I think the biggest
> issues
> > stem from two false assertions:
> > 1) "TLD operators are being asked to do this as they...have access to a
> > large numbers of nameserver names as well as contact details for the
> > registrants of those nameservers."
> >
> > This is incorrect.  Or, at least, frequently incorrect.  TLD registries
> > fall into one of two categories: thick or thin.   Thick registries do
> have
> > this information, but a significant number of thin regi

Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[Matthew Pounsett]

On 10 October 2016 at 12:33, Viktor Dukhovni  wrote:

> On Tue, Oct 11, 2016 at 01:56:42AM +1100, Mark Andrews wrote:
>
> > If the IETF was setting servers that went and checked DNS servers
> > and informed the operators then the IETF would be in the business
> > of enforcing protocols.  At this stage I don't see the IETF doing
> > that nor is this document asking the IETF to do that.
> >
> > The is a difference between innovation and not exercising care /
> > lazyness.
> >
> > Returing FORMERR because you see a EDNS flag you don't understand
> > is not innovation.
> >
> > Returing FORMERR because you see a EDNS option you don't understand
> > is not innovation.
> >
> > Returing FORMERR because you see a EDNS version you don't understand
> > is not innovation.
> >
> > If there was anything innovative in what I'm seeing I'd be all for
> > it but there isn't.
>
> Amen.  This draft documents widely problematic behaviour that is
> seen much too often.  It is good to have it all written down in
> one place.
>

I agree.  It is very useful in that respect.

The specific issue we're discussing here is whether the draft can/should
require certain actions from DNS operators based on the behaviour of child
zones.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Matthew Pounsett]

On 28 September 2016 at 10:29, Shumon Huque <shu...@gmail.com> wrote:

> On Wed, Sep 28, 2016 at 11:39 AM, Matthew Pounsett <m...@conundrum.com>
> wrote:
>
>>
>>
>> On 28 September 2016 at 06:42, Edward Lewis <edward.le...@icann.org>
>> wrote:
>>
>>> On 9/27/16, 18:46, "Matthew Pounsett" <m...@conundrum.com> wrote:
>>> >Would it be better then to leave early expiry as an implementation
>>> choice
>>>
>>>
>>> Ultimately, the goal of the draft is to tell a recursive server that if
>>> it can conclusively deduce existence of a name from what it has cached, it
>>> is allowed to do so.  Today if the conclusion is positive, that's how it
>>> is.  The draft proposes to add negative conclusions as well.  Perhaps
>>> getting into the details of managing what's in the cache, which is not
>>> covered beyond TTL expiry "rules" is causing the wrapping around the axle.
>>> (We are talking about the fairly odd example of there being conflicting
>>> data.)
>>>
>>>
>> Taking the view that this is only about interoperability, then I would
>> say the implementor MAY treat names below the NXDOMAIN response as
>> nonexistent, and MAY choose to expire those names early... perhaps with a
>> suggestion that this might be the better choice for data coherence, but
>> still leave it up to the implementor if they've got a better reason to do
>> it otherwise.
>>
>
> The draft (by working group consensus) is written as "SHOULD treat names
> below as non-existent", but "MAY continue to answer existing positive
> cached entries". I think this managed to cover or at least placate all
> positions expressed by working group participants leading up to the last
> call.
>
> I'm not sure we'll get new agreement on your proposed revision.
>
> I phrased that badly.  Since we were on the subject of cached entries
already, I assumed that context in my wording.   I should have said "MAY
treat positively cached names below the NXDOMAIN response as nonexistent,
and MAY choose to expire those cached names early."  I think that's in
keeping with the intent of the current text.

There's probably some value in rewording that text though, if it's going to
cause confusion for implementors.  Maybe invert the text?

# When an interative caching DNS resolver receives a response NXDOMAIN, it
# SHOULD store it in its negative cache.  It MAY choose to immediately
remove
# from its positive cache any previously cached names at or below the
NXDOMAIN
# response.  If the cached entries below the NXDOMAIN response are not
# removed, it MAY choose to continue to answer positively for those names
# until the cached entries expire.

# The resolver SHOULD treat all other names at or below NXDOMAIN response
as
# nonexistant and SHOULD respond negatively to queries for such names.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Matthew Pounsett]

On 28 September 2016 at 06:42, Edward Lewis <edward.le...@icann.org> wrote:

> On 9/27/16, 18:46, "Matthew Pounsett" <m...@conundrum.com> wrote:
> >Would it be better then to leave early expiry as an implementation choice
>
>
> Ultimately, the goal of the draft is to tell a recursive server that if it
> can conclusively deduce existence of a name from what it has cached, it is
> allowed to do so.  Today if the conclusion is positive, that's how it is.
> The draft proposes to add negative conclusions as well.  Perhaps getting
> into the details of managing what's in the cache, which is not covered
> beyond TTL expiry "rules" is causing the wrapping around the axle.  (We are
> talking about the fairly odd example of there being conflicting data.)
>
>
Taking the view that this is only about interoperability, then I would say
the implementor MAY treat names below the NXDOMAIN response as nonexistent,
and MAY choose to expire those names early... perhaps with a suggestion
that this might be the better choice for data coherence, but still leave it
up to the implementor if they've got a better reason to do it otherwise.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[Matthew Pounsett]

My first impression of this document is that it is still in need of some
extreme editing – mostly for grammar and syntax, but also for clarity and
readability.  I've included many of the early problems I found in a list of
nits at the end of this email, but at two and three errors per paragraph
(and occasionally per sentence) it's just too much to cover this way, so I
stopped noting nits after the first couple of sections.  I suggest such
sweeping changes to later sections that any nits I noted there may end up
being rewritten anyway.

The draft still suffers from inconsistent approaches to the content.  In
any given section it might shift from a problem description, to
admonishment, to advice for workarounds, and back again without a clear or
consistent structure.  This makes it difficult to figure out what the
intended takeaway is in places.  I've tried to point out specifics below,
and suggest better approaches where I can.

Don't let my criticism of the document give you the wrong impression.  I
think this is useful work, and I'm very appreciative of the work that has
gone into it so far.  I just happen to think that there is still work left
to be done.


As for the meat of the matter...


In the Introduction, in the paragraph which begins "Unless a nameserver is
under attack" would it make sense to replace "broken delegations" with
"lame delegations"?   We have a term for delegating to a name server which
is not authoritative for the delegation... we should probably use it.


Section 2, "Consequences," seems out of place to me.  It makes a number of
assertions that seem to follow no particular flow, or pattern.  The line of
reasoning or evidence that lead to these assertions has not appeared yet in
the document, and so they seem unsupported.  If I'm interpreting the
author's intent correctly, perhaps this section should be split up and
interspersed into the current section 3 as the direct or indirect
consequences of each type of dropped response.


The way section 3 is titled and introduced I expect to just see a survey of
commonly dropped queries, but the content seems to be inconsistent as to
whether it's just a survey, or a survey and advice to client authors about
working around problems, or just advice without a clear description of the
problem behaviour.  It seems to me that if the section is intended to be
advice to authors, then it should be introduced that way.  Also,
clarification for server authors on how they should respond–instead of
dropping queries–should probably come before any advice on how to work
around dropped queries.

If the goal here is to help implementors fix what's broken, then I would
suggest each subsection start with a clear description of an observed
broken behaviour, followed up with a description of how that behaviour
should change (possibly only as a short summary with external references,
as we don't want to reproduce whole RFCs here) and then follow that with
advice for client authors for working around existing brokenness.  Sticking
to a pattern–either the one I've suggested or some other–for every query
type would make the entire section easier to read.  It will also make it
easier for the working group to go through the section item by item and
discuss whether we agree on the problem descriptions and proposed
remediation.

RFC 2119 language is conspicuously absent from this section and SHOULD be
added.


Section 4, "Remediating", is very problematic.  I think the biggest issues
stem from two false assertions:
1) "TLD operators are being asked to do this as they...have access to a
large numbers of nameserver names as well as contact details for the
registrants of those nameservers."

This is incorrect.  Or, at least, frequently incorrect.  TLD registries
fall into one of two categories: thick or thin.   Thick registries do have
this information, but a significant number of thin registries exist, which
delegate the responsibility for maintaining registrant contact information
to the registrar.  All thin registries know is that a delegation should
exist, which name servers are currently supposed to be authoritative for
the subzone, and which registrar asked them to create the delegation.

This false assertion leads the author down the path of making the TLD
registry responsible for contacting registrants.  The third paragraph
backpedals a bit on the question of who should be doing what, but then the
rest of the section goes on to talk about the registry anyway.

A lot of text could be removed from the first few paragraphs by removing
the need to soften the initial statement that this responsibility lies with
the TLDs.

2) The second false assertion is the implied assertion that RFC 1033 says
anything at all about a zone operator's responsibility to remove
delegations that lead to badly behaving name servers.

To provide context ... the title of RFC 1033 is "DOMAIN ADMINISTRATORS
OPERATIONS GUIDE," and the first sentence of the referenced COMPLAINTS
section is,