Re: [DNSOP] Unknown DNS RDATA type presentation syntax vs. e.g. TXT records?

[神明達哉]

At Sun, 9 Feb 2020 04:28:14 -0500,
Viktor Dukhovni  wrote:

>  --->  An implementation MAY also choose to represent some RRs of known type
>  --->  using the above generic representations for the type, class and/or
>  --->  RDATA, which carries the benefit of making the resulting master file
>  --->  portable to servers where these types are unknown.  Using the generic
>representation for the RDATA of an RR of known type can also be
>useful in the case of an RR type where the text format varies
>depending on a version, protocol, or similar field (or several)
>embedded in the RDATA when such a field has a value for which no text
>format is known, e.g., a LOC RR [RFC1876] with a VERSION other than 0.
>
>  --->  Even though an RR of known type represented in the \# format is
>  --->  effectively treated as an unknown type for the purpose of parsing the
>  --->  RDATA text representation, all further processing by the server MUST
>  --->  treat it as a known type and take into account any applicable type-
>specific rules regarding compression, canonicalization, etc.
>
> In particular the middle paragraph's *MAY* could appear to suggest that
> the choice is not just one of output format, but that *on input* parsers
> don't need to support the generic "\#  " form for
> *known* types.
>
> I don't read it that way, rather my reading is that the generic RDATA
> format MAY be selected on *output* for portability reasons, but *should*
> MUST be supported for all types, whether known or unknown, on input.

It would be nice if we could clarify the meaning of this "MAY".  I've
also encountered an implementation (not BIND 9) that rejects the
RFC3597 form of RDATA for types that the implementation already
explicitly supports (e.g., type ).  I was about to submit a bug
report but on re-reading the RFC and found this "MAY", and wondered
whether this allows such an implementation to still claim to be
compliant.

I personally agree with your interpretation, but the text could
actually be clearer.

--
JINMEI, Tatuya

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

Re: [DNSOP] valid value range for SOA REFRESH/RETRY/EXPIRE

[神明達哉]

At Fri, 18 Oct 2019 10:49:40 +1100,
Mark Andrews  wrote:

> > > > one obvious interpretation is that REFRESH/RETRY/EXPIRE are signed
32
> > > > bit integers.
> > >
> > > They are all intervals.  How do you have a negative interval?
> >
> > I actually didn't expect they can be negative.  My main question is
> > whether values larger than 2^31-1 should be considered valid.
>
> Well they are in range.

I was not sure if they are really "in range".  If the RFC explicitly
says "*unsigned* 32-bit time interval", yes, but with the lack of
"unsigned" (while explicitly using "unsigned" for SERIAL and MINIMUM)
it seemed ambiguous.  That's why I asked the question in the first
place.

> That said slaves can and do apply sanity
> checks to these values.  Both too low and too high cause operational
> problems.

Agreed, I already noted essentially the same point in my first message.

Anyway, my interpretation of the responses so far (or the lack of
thereof) is that no one knows (or cares about) the exact range (per
protocol standard) for these parameters.  That's not the best result I
wished to see, but at least it looks like I didn't miss anything
obvious for others.

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

Re: [DNSOP] valid value range for SOA REFRESH/RETRY/EXPIRE

[神明達哉]

At Fri, 18 Oct 2019 10:25:29 +1100,
Mark Andrews  wrote:

> > one obvious interpretation is that REFRESH/RETRY/EXPIRE are signed 32
> > bit integers.
>
> They are all intervals.  How do you have a negative interval?

I actually didn't expect they can be negative.  My main question is
whether values larger than 2^31-1 should be considered valid.

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

[DNSOP] valid value range for SOA REFRESH/RETRY/EXPIRE

[神明達哉]

I have a question for which I believe there's an answer already that I
couldn't find: what's the valid range for SOA REFRESH/RETRY/EXPIRE
values?

RFC1035 says:

  REFRESH A 32 bit time interval ...
  RETRY   A 32 bit time interval ...
  EXPIRE  A 32 bit time value ...

and since it explicitly uses "unsigned" for SERIAL and MINIMUM, e.g:

  SERIAL  The unsigned 32 bit version number of the original copy

one obvious interpretation is that REFRESH/RETRY/EXPIRE are signed 32
bit integers.  And, since negative values for these don't make much
sense, we might even interpret it similar to RR TTLs as clarified in
RFC2181, i.e., 0 <= REFRESH/RETRY/EXPIRE <= 2^31-1.

Is this correct?  Implementations seem to vary on this point, btw.
>From my quick experiment with some code reading,
- BIND 9 accepts any unsigned 32-bit values
- Same for Knot
- NSD treats them like TTL (values >= 2^31 are reduced to the "default
  TTL" value)
(I've only checked at the primary side; I didn't do any test how the
secondary side of the implementation uses these values when they are
very large).

Such huge values for these parameters don't make sense in practice
anyway, so this is probably a pedantic question.  But if anyone knows
an authoritative reference that can answer it I'd appreciate it very
much.

Thanks,

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

Re: [DNSOP] Fwd: HTTPSSVC record draft

[神明達哉]

At Tue, 23 Jul 2019 17:04:43 +0200,
Matthijs Mekking  wrote:

> But as soon as clients start querying for ANAME (and not address
> records) meaning it will chase the target itself, the DNS server
> actually does not have to do a target lookup anymore.

True, but my understanding is that the key difference is that the web
browser community (at least some big players of it) is willing to
support HTTPSSVC, thereby already overcoming the most difficult part
of the chicken-and-egg problem: how to deploy it in the client side.
I actually don't fully understand how HTTPSSVC has got the support
while ANAME hasn't though (perhaps because of the incentive of other
HTTPSSVC features like the alternative service form?).

Once a sufficient number of clients support it, the authoritative side
will have the incentive of deploying HTTPSSVC, and if it's
sufficiently deployed in the authoritative side, too, then we can
eventually hope to deprecate the practice of CNAME at apex.

Right now, I'm not sure how we can expect this to happen for ANAME
(except by waiting for perhaps several decades, until almost all
recursive servers natively support ANAME).

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

Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information

[神明達哉]

At Sat, 29 Jun 2019 22:55:07 +,
Paul Hoffman  wrote:

> > - I think the RESINFO RDATA specification (at least its wire format,
> >   and preferably also the presentation format) should be more clearly
> >   specified.  At least to me it was not very clear, and I'm afraid
> >   this can lead to interoperability problems.
>
> It is a JSON object. What beyond that description would help?

For example, if it can be a part of a standard zone file, what's the
expected presentation format?  Is it a la TXT character string (but
there's no length limitation) or something special?  How do we handle
non-ascii characters?

Also, how do we compare RESINFO RDATAs?  Should they be compared as
opaque binary, or should two semantically identical JSON objects
considered equal as RESINFO RDATA too (even if, for example, they are
different regarding white spaces)?

> > - The last sentence of Section 2 doesn't make sense to me:
> >
> >they only need code to handle the RESINFO RRtype that is not in
> >.{in-addr,ip6}.arpa/IN or a subdomain of  >ip>.{in-addr,ip6}.arpa/IN .
> >
> >   Should it actually be "that is in" instead of "that is not in"?  If
> >   it's really "not in", I don't know how to interpret this in this
> >   context...
>
> The whole sentence is confusing, and we can remove it. Thus, that whole
paragraph can go away.

It may depend on the original intent of the NODATA/NXDOMAIN
restriction, but I'm personally fine with that.

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

Re: [DNSOP] Request for adoption: draft-sah-resolver-information

[神明達哉]

At Thu, 27 Jun 2019 18:44:09 +,
Paul Hoffman  wrote:

> Greetings. We have again updated draft-sah-resolver-information
> based on comments from this mailing list. We think that this is
> ready for adoption by the WG so that the initial use of the protocol
> (to be able to determine the URI template of the DoH server
> preferred by your current resolver) can move forward as well.

I don't have a strong opinion on the adoption, but I'm willing to
review it.  My comments on 02 follow:

- I think the RESINFO RDATA specification (at least its wire format,
  and preferably also the presentation format) should be more clearly
  specified.  At least to me it was not very clear, and I'm afraid
  this can lead to interoperability problems.

- It was not clear to me how the RESINFO is supported or not supported
  by authoritative servers.

  Section 1 states:
   [...]  Authoritative
   servers MUST NOT answer queries that are defined in this protocol.

  But Section 2 states:

   [...] if the resolver can be configured to
   also be authoritative for some zones, it can use that configuration
   to actually be authoritative for the addresses on which it responds.

  This sounds like an "authoritative server" may answer those queries
  (perhaps Section 1 means "real" authoritative servers, and
  authoritative only servers in particular, while Section 2 intends to
  mean "local zone" features often available in recursive server
  implementations.  But that's not really clear from the text.)

  And  Section 6 states:

   [...] or unless the
   .{in-addr,ip6}.arpa zone is signed with DNSSEC, the
   response is susceptible to forgery.

  This seems to implicate that RESINFO under a
  .{in-addr,ip6}.arpa zone could be signed and answered by
  its authoritative server.

  I think the draft needs to clarify the expected role or limitation
  of authoritative servers regarding the proposed protocol.

- (Somewhat related to the previous point) Section 2 states

   Any query for the RESINFO RRtype that is not in .{in-
   addr,ip6}.arpa/IN or a subdomain of .{in-addr,ip6}.arpa/
   IN is meaningless and MUST result in a NODATA or NXDOMAIN response.
   Resolvers would not need any special code to meet this requirement;
   [...]

  How can we enforce (with a MUST) the result of NODATA or NXDOMAIN,
  especially if the resolver doesn't do anything special for such a
  case?  If it means the resolver could just try to resolve it with
  authoritative servers and we require authoritative servers return
  NODATA or NXDOMAIN, can we always assume that?  What if the zone's
  administrator configure a zone including the RESINFO?  (And in any
  case, wouldn't it contradict the MUST NOT in Section 1?)

- The last sentence of Section 2 doesn't make sense to me:

   they only need code to handle the RESINFO RRtype that is not in
   .{in-addr,ip6}.arpa/IN or a subdomain of .{in-addr,ip6}.arpa/IN .

  Should it actually be "that is in" instead of "that is not in"?  If
  it's really "not in", I don't know how to interpret this in this
  context...

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

Re: [DNSOP] ANAME precedence [issue #58]

[神明達哉]

At Fri, 26 Apr 2019 09:16:58 +0200,
Matthijs Mekking  wrote:

> > Also, especially if both  and A sibling records are available,
> > what's the purpose of ANAME in the first place if it's (effectively)
> > not used?
> >
> > I'm sure I'm just confused and don't understand the expected usage,
> > but I can't figure it out from the available descriptions.  Could you
> > clarify it?
>
> Personally I agree that the purpose of ANAME becomes less useful with
> choice #2.  The difference is that you can set up ANAME for example for
>  only, or for A only. I don't know what the expected usage of that
> is, and that is why I am asking on the list. If it turns out there is no
> useful case, I think we should put text in the draft that says ANAME
> takes precedence over sibling A and  records.

Okay.  In that case I agree we should go for choice #1 (ANAME should
be preferred) unless the expected usage for choice #2 is clarified and
convinces us (the wg).  Choice #2 looks awkward to me especially if we
consider the case where both  and A siblings exist.

According to your original message choice #2 was derived from the
behavior of a particular implementation:

> Jan Včelák mentioned that at least NS1 uses a different order of
> priority: If an sibling address record exists next to the ANAME it takes
> precedence and no target lookup is done for that address record type.

if there's a specific use case where this behavior is important,
either the developer or user of this implementation should be able to
clarify that.  At least until we know that I don't see the point of
considering this choice.

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

Re: [DNSOP] ANAME precedence [issue #58]

[神明達哉]

At Wed, 24 Apr 2019 11:44:37 +0200,
Matthijs Mekking  wrote:

> I would like to start separate threads on the remaining issues of the
> ANAME draft. One issue that remains to be solved is whether having an A
> or  record next to the ANAME should take precedence or not.
>
>   Draft: https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/
>   Issue: https://github.com/each/draft-aname/issues/58
[...]
> Jan Včelák mentioned that at least NS1 uses a different order of
> priority: If an sibling address record exists next to the ANAME it takes
> precedence and no target lookup is done for that address record type.

Is this choice #2 of the github issue #58?

>> sibling address records take precedence, don't to a target lookup for an
address type next to the ANAME.

I'm not sure what this means...if this approach is taken and an
authoritative server has these for an example.com zone:

a.example.com. ANAME another.example.org.
a.example.com.  2001:db8::1

then, does it always just return the  RRset to a query for
a.example.com/, regardless of any possible changes to
another.example.org/?

How is that  created in the first place?  (Is it taken from
another.example.org/ or completely up to the example.com
maintainer?).

Also, especially if both  and A sibling records are available,
what's the purpose of ANAME in the first place if it's (effectively)
not used?

I'm sure I'm just confused and don't understand the expected usage,
but I can't figure it out from the available descriptions.  Could you
clarify it?

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

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

[神明達哉]

At Wed, 20 Mar 2019 12:38:05 +0100,
Joe Abley  wrote:

> > Often as an industry we may discuss various solutions that are great
for oneself but don’t scale when looking at the big picture.
>
> I think what we are seeing is the fundamental tension between privacy and
control. You need to give up some privacy in order to make the control
possible; you need to give up some control in order to afford privacy.

> Some in this thread want certainty that they are able to exercise
control, e.g. for devices in their network.

> Some in this thread want certainty that they can obtain privacy, e.g. for
for their device in any network.

[...]

Thank you for the nice, concise summary.  I think it's well-balanced
observation of where we are.  (I'm so glad I can finally see a
constructive post after seeing a common pattern of boring IETF
discussion, where people with different opinions just keep stating
their views without making any real progress:).

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

I see that those who want to exercise control can live with this (or
at least using a different set of IP addresses for DoH servers than
those for other ordinary web services).  But I'm not so sure if that's
acceptable for the other group.  In that sense I'm curious whether
some big possible DoH providers are now willing to accept this middle
ground.  If my memory is correct the longer term plan at Google (and
maybe also Clouldflare?) is to provide DoH service on the same IP
addresses as those for other ordinary and popular web services (and on
port 443, of course), so that an intermediate operator cannot easily
block access to their DoH services.

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

True.  But I think giant providers tend to respect a community
consensus.  Niche or really malicious players may/will still ignore
it, but it would be very difficult for them to collocate their DoH
services with other important web services that can hardly be blocked,
so it shouldn't be a big problem for "those who want certainty of
control".  So if we can really agree on the above "middle ground" and
publish a BCP or something that describes the consensus, I guess we
can now really work on technical issues.  But I'm not sure if we can
reach that consensus.

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

[DNSOP] dnsop meeting agenda?

[神明達哉]

There's still no link to meeting agenda of dnsop sessions on the
IETF104 agenda page: https://datatracker.ietf.org/meeting/104/agenda/

Is it some kind of operation error or is the agenda still unavailable?
If it's the latter, when can we expect to see it?

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

Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt

[神明達哉]

At Mon, 4 Mar 2019 19:45:02 -0500,
Tom Pusateri  wrote:

> Thanks to the great feedback, we were able to update the document to
> better match the preferences of the working group and address the
> outstanding concerns.

> > A new version of I-D, draft-pusateri-dnsop-update-timeout-02.txt
> > has been successfully submitted by Tom Pusateri and posted to the
> > IETF repository.

I've read draft-pusateri-dnsop-update-timeout-02.  Personally, I'm not
yet convinced that we need to provide this functionality in an
"in-band" way (i.e., as a DNS resource record).  But I wouldn't
be strongly opposed to it if the WG is willing to adopt it.  For now
I'm just providing some technical comments on the draft content.

- general: it's not clear to me when/how a TIMEOUT RR is added to a
  zone?  Is it assumed that an update client includes it in its update
  request?  Or is the primary server supposed to internally add/update
  TIMEOUT(s) on handling update requests?  Or something else?  I think
  the draft should explain it more clearly.

- Section 4

   If the expiry time is the same,
   multiple records can be combined into a single TIMEOUT record with
   the same owner name, class, and record type but this is NOT REQUIRED.

  'NOT REQUIRED' is not an RFC2119 keyword.  If this is not intended
  to be a normative keyword, it's better to be lower-cased to avoid
  confusion; if it's intended to be normative, a valid RFC2119 keyword
  should be used.

- Section 4.1

   A 16-bit field containing the resource record type to which the
   TIMEOUT record applies.  Multiple TIMEOUT records for the same owner
   name, class, and represented type can exist.

  Is there any RR type that must not be specified here?  For example,
  can TIMEOUT itself be specified?

- Section 4.2

   If an additional TIMEOUT record exists with the same
   owner name, class, and record type, it MUST be ignored and SHOULD be
   removed.

  It's not clear to me exactly what "it MUST be ignored and SHOULD be
  removed" means...perhaps it's also related to how TIMEOUT is added
  to a zone.

- Section 4.3.2

   The record MUST be in canonical DNSSEC
   form as described in Section 6 of [RFC4034].

  You might also want to state that the RDATA in TIMEOUT and the RDATA
  of the actual RR that it covers must be compared in the canonical
  form (i.e., some types of RRs have to be compared in the
  case-insensitive manner).

- Section 6

   A TIMEOUT resource record MUST be removed when the last resource
   record it covers has been removed.

  This statement looks ambiguous about *who* removes the TIMEOUT.
  According to the paragraph that follows I guess it's the primary
  server implementation (rather than, e.g., a human administrator of
  the server).  Perhaps it's better to use the active voice here, too:

A primary server MUST remove a TIMEOUT resource record...

- Section 6/general: what should happen if an administrator manually
  edit the zone file (and reload it to the primary server)?  Is it the
  administrator's responsibility to adjust TIMEOUT accordingly, or is
  the primary server implementation supposed to do it automatically?

- Section 6

   As a reminder from Section 3.3.13 of [RFC1035], the MINIMUM field of
   the SOA for the zone is used as a lower bound of the TTL for all
   records in the zone.

  This is deprecated by RFC2308.

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[神明達哉]

At Fri, 8 Mar 2019 12:03:27 -0500 (EST),
Paul Wouters  wrote:

> [my last email in this thread. I don't think we are progressing and I'd
>   like to give others a chance to participate in this thread. But feel
>   free to reply]
>
> >>  But assigned and left completely opague is not really suitable for
> >>  "heterogenous off-the-shelf software". These different vendors must
> >>  understand the meaning of the opaque data even if their functionality
> >>  can be non-standard.
> >
> > No, it does *not* require that at all.
>
> Unless the implementations just log these numbers, they are expected to
> do or trigger something. Either with their own interpretation, or by
> some helper process or configuration magic interpreting these things for
them.

+1.  It's very difficult for me to imagine how we can expect that two
"heterogenous off-the-shelf software" products can be interoperable
just because we have a standardized EDNS option code for opaque tags.

For example, assume that an operator uses dnsdist as a DNS load
balancer and BIND 9 as backend servers with RRL, and the operator
wants to trust particular clients (identified by their IP addresses)
and bypass RRL for them.  How can we expect off-the-shelf dnsdist and
off-the-shelf BIND 9 support this operation with the only assumption
being that both of them support edns-tags?  Is there an implicit
assumption that:
- this version of off-the-shelf dnsdist happens to have a new
  configuration option so it will add an edns-tag with setting bit X
  when the client IP address matches a specified set of address list,
- this version of off-the-shelf BIND 9 happens to have a new
  configuration option to skip RRL if an incoming request contains an
  edns-tag option with bit X on
?

At this moment I don't have a strong opinion on the proposal itself,
but the "off-the-shelf software" argument doesn't sound very
convincing or realistic.  Perhaps I miss some implicit assumptions, in
which case I'd like the draft to explain these in more detail.

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

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

[神明達哉]

I've read draft-ietf-dnsop-serve-stale-03.  In addition to the
high-level draft organization matter I mentioned in another thread,
here are my other comments on this version:

- Section 4:

   The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is
   amended to read:

   TTL  [...]  If the authority for the data is unavailable
  when attempting to refresh, the record MAY be used as though it is
  unexpired.

  On understanding that this is the only real normative description,
  I'd suggest making some more points explicit to prevent abusing of
  this leniency:
  - explicitly say "all authoritative servers" instead of just "the
authority"
  - also explicitly note that this MUST NOT be allowed if at least one
authoritative server is available
  - clarify whether this means a 0-TTL record can be cached and reused
under this condition (I assume it must not, but it's not very clear
to me)

- Section 5

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

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

- Section 5

   Outside the period of the resolution recheck timer, the resolver
   SHOULD start the query resolution timer and begin the iterative
   resolution process.

  It's not clear to me how this timer is related to the 'server-stale'
  behavior; this draft doesn't explain what happens when this timer
  expires, for example.  Also, in my understanding unbound doesn't
  have this timer - it eventually gives up a resolution if all
  possible external query fails with a per-query timeout, but it
  doesn't cap the overall resolution time.  That may not matter much
  as this section doesn't seem to be normative and it's just an
  implementation detail of a particular implementation, but if the
  role of this timer doesn't matter either, we might rather simplify
  the text by just omitting it.

- Section 6

   Stale data is used only when refreshing has failed, in order to
   adhere to the original intent of the design of the DNS and the
   behaviour expected by operators.

  I agree on this statement, but I wonder how widely this behavior is
  actually implemented.  As noted in Section 7, unbound doesn't behave
  this way, and in my understanding it's intentional, mainly due to
  a concern about related IPR.  If that's more common for other open
  source implementors (BIND 9 seems to work as described here, but I
  don't know about others), the description won't match the actual
  implementation behavior very well in reality.  So I'm curious about
  implementation status about this point, and if many different
  implementations intentionally ignore this "caveat" for the same
  reason, I think we should adjust the text to match the reality.

- Section 7

   Unbound has a similar feature for serving stale answers, but will
   respond with stale data immediately if it has recently tried and
   failed to refresh the answer by pre-fetching.

  If I understand the implementation correctly, this is not 100%
  accurate: unbound always return the stale data if it's found in the
  cache as long as the "serve-expired" option is enabled.  So I
  suggest revising the text to:

   Unbound has a similar feature for serving stale answers, but will
   respond with stale data immediately whenever the feature is
   enabled.

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

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

[神明達哉]

At Fri, 1 Mar 2019 15:54:39 -0500,
Dave Lawrence  wrote:

> > I'm not sure a standards track document that updates RFC 1034/1035
> > should be recommending a minimum TTL.
>
> As previously noted, we're making no such recommendation and that will
> be clarified.  The first definition of "resolution recheck timer" in
> section 5 does already say that it regards failed lookups, but it
> seems that adding that distinction later is also warranted.
>
> > The document is actively confusing about recommendations.
>
> Before we go pushing around whole sections of text, could anyone
> please comment on whether they find it "actively confusing about
> recommendations"?

FWIW: "actively confusing" may be too strong, but I also found it
confusing on my fresh re-read of serve-stale-03 in that the "example
method" section contains normative descriptions using RFC2119
keywords.

So I support Paul's proposal:

>> Proposal: Put all recommendations in Section 4, and talk about them
>> (instead of introducing them) in the other sections. That way, a
>> lazy developer who only reads Section 4 will know all the
>> recommendations.

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

Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt

[神明達哉]

At Mon, 04 Mar 2019 20:43:14 +0900 (JST),
fujiw...@jprs.co.jp wrote:

> > - Section 3
> >
> >Linux 2.6.32, Linux 4.18.20
> >and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and
> >path MTU decreased to 1280.
> >
> >   I suspect this often doesn't matter much in practice.  Since IPv6
> >   doesn't allow fragmentation and PMTU discovery isn't very effective
for
>   ^
>   on-path fragmentation ?

Oops, sorry for the confusing text.  I meant "IPv6 doesn't allow
fragmentation at intermediate nodes" (or, yes, I meant "on-path
fragmentation").

> >   DNS responders, the server implementation should set
> >   IPV6_USE_MIN_MTU and expect that MTU anyway (several implementations
> >   actually set this option; some others don't, but they are just lucky
> >   to not encounter the problem or receive complaints about it).
>
> If setting IPV6_USE_MIN_MTU, does the server use 1280 as all path MTU
value ?

Yes.  Or more accurately, if IPV6_USE_MIN_MTU is set the path MTU
value (if known) is just ignored.

> Without IPV6_DONTFRAG option, are responses larger than 1280 fragmented ?

Yes (if IPV6_USE_MIN_MTU is specified).

> I observed many fragmented IPv6 DNS responses whose packet size are
> 1496 or 1500.

Those should be sent from a server that doesn't set IPV6_USE_MIN_MTU
or from a system that doesn't support the option (sadly a very widely
deployed OS doesn't support it: Linux).

> # What I was interested in was that many implementations accept
> # crafted "ICMPv6 Packet Too Big".

Sure, but unless it matters in the larger context of the draft, it's
just a distraction.

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

Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt

[神明達哉]

At Fri, 01 Mar 2019 21:14:48 +0900 (JST),
fujiw...@jprs.co.jp wrote:

> Dear DNSOP,
>
> I submitted draft-fujiwara-dnsop-fragment-attack-01.
>
>https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01
>
> It summarized DNS cache poisoning attack using IP fragmentation
> and countermeasures.
>
> If the draft is interested, I will request timeslot at IETF 104.

I've read the draft.  I think it's generally well written and contains
useful information.

Some specific comments follow:

- general: I wonder whether the effect of this problem can be
  substantially different between IPv6 and IPv4.  As the draft itself
  discusses, IPv6 has a much larger ID space for fragmentation (the
  existence of implementations that generate predictable IDs is an
  implementation issue; in the case of IPv4 it's a protocol issue).
  IPv6 also has a much larger minimum MTU.  In practice, I suspect
  most (unsigned) important responses can fit in the minimum MTU,
  substantially affecting the practical severity of the attack.  I'm
  not saying that we don't have to take any measure for the IPv6 case,
  but I think this difference is worth noting in the draft explicitly.

- general: the draft the term "full-service resolver" in Abstract and
  throughout the document.  It may be only me, but I always feel this
  term is confusing and misleading, even after the publication of
  RFC8499.  It's not very clear to me whether "full-service" excludes
  "forwarding only" resolvers.  RFC8499 refers to RFC1123, and its
  definition is also unclear to me in this sense.  If this confusion
  is not only mine, I think the use of the term is rather harmful,
  since the issue discussed in this draft shouldn't exclude forwarding
  only resolvers.  What matters here is a resolver with a cache, and
  in that sense I'd rather suggest just saying "(recursive) resolver";
  it should be obvious that it's about a resolver with the cache from
  the context.

- general: on a related point, I suspect the discussion about
  authoritative servers is not actually specific to authoritative
  servers; consider the case of a recursive server that takes queries
  from forwarding only resolvers.  It should be generally applicable
  to any DNS "responder", and I'd suggest revising the draft
  accordingly.

- general: since this is about off-path cache poisoning attacks, you
  may also want to refer to DNS cookies (RFC7873) as a possible measure.

- Section 3

   Linux 2.6.32, Linux 4.18.20
   and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and
   path MTU decreased to 1280.

  I suspect this often doesn't matter much in practice.  Since IPv6
  doesn't allow fragmentation and PMTU discovery isn't very effective for
  DNS responders, the server implementation should set
  IPV6_USE_MIN_MTU and expect that MTU anyway (several implementations
  actually set this option; some others don't, but they are just lucky
  to not encounter the problem or receive complaints about it).

- Section 4.2

   Limiting EDNS0 requestor's UDP payload size [RFC6891] to 1220/1232 on
   IPv6 is a measure of path MTU attacks on IPv6 because minimal MTU
   size of IPv6 is 1280 and most of implementations ignore ICMPv6 packet
   too big packets whose MTU size is smaller than 1280.

  I suggest removing "and most of implementations..." since even if an
  implementation accepts ICMPv6 PMTU with MTU < 1280, it doesn't mean
  they fragment packets at that size.

- Section 4.8

   Some operators that support [RFC8078] said that they use TCP only for
   transport to avoid cache poisoning attacks.

  It's not clear (to me at least) how RFC8078 is related to a TCP-only
  operation.  Some more explanation may help.

- Section 5

   o  Full-service resolvers may retry name resolution by TCP.

  I don't get exactly what this means...in which case does it suggest
  the retry with TCP?

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

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

[神明達哉]

At Wed, 20 Feb 2019 07:51:51 -0500,
Joe Abley  wrote:

> The crux of the use case seems to be that it is commonplace for names in
the DNS to exist for short periods of time and that for some applications a
name that overstays its welcome can cause an operational problem.
>
> While I can understand the philosophical desire to complete the UPDATE
specification so that it is possible to engineer around this scenario, I
don't see the practical application.

I happen to know there's a practical application related to this
proposal.  As Mark says not all DHCP servers behave politely; there
are servers that just add RRs via DDNS and forget them.  We could say
that it's a problem of poorly implemented DDNS clients, not something
that should be solved in the DNS protocol.  I wouldn't necessarily be
opposed to that view.  In fact, given the higher bar with the "camel"
test, I'm not yet really convinced about the need for a protocol-based
solution to this problem either.  But at least this is related to a
practical problem, not just a philosophical one.

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

Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

[神明達哉]

At Fri, 8 Feb 2019 00:39:27 +0530,
Mukund Sivaraman  wrote:

> > The draft doubles the number of packets involved in a legitimate
> > exchange; it more than doubles the number of packets involved in a
> > spoofed exchange. About half of these packets are ICMP
> > packets. Without the draft, ICMP packets are useful debugging aids,
> > and in big numbers, indications of attacks or operational
> > problems. With the draft, ICMP becomes another useless source of
> > background noise.
>
> I had implemented the draft about a year ago as a server-side patch for
> BIND so that it could be tried/tested. But I was not aware of the ICMP
> issue that you mentioned. Today I looked at a packet capture with ATR
> response and sure enough, the 2nd truncated response generates an ICMP
> message from the recipient. I agree that this would be noisy.

Probably off topic in the context of the adoption call, but I'd note
that it depends on some implementation details of the resolver.  ICMP
port unreachable errors will be likely to be increased if the resolver
closes the UDP socket for a query with an authoritative server
immediately after it receives a return packet.  BIND behaves that way
by default, so did PowerDNS recursor when I checked the implementation
many years ago (it probably still does).  But not all resolver
implementations adopt this practice; if I understand it correctly
Unbound uses a pool of (many) UDP sockets and reuse the same socket
for multiple queries.  I've not tested it myself but I believe you
won't see an increase of ICMP errors with such resolver
implementations.

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

Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

[神明達哉]

At Fri, 18 Jan 2019 18:55:16 +0100,
Benno Overeinder  wrote:

> We discussed this work (draft -01) in Montreal, and different opinions
wrt. adoption were expressed.  In the past months, the authors pushed a
draft version -02 that addressed and resolved some of these comments.
>
> This starts a Call for Adoption for:
> draft-song-atr-large-resp
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-song-atr-large-resp/
>
> 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.

I've read draft-song-atr-large-resp-02.  I support the adoption of
this doc, or at least of *some work* related to the "large response
drop" problem, by DNSOP.  If adopted I'm willing to review subsequent
versions.

I don't have empirical measurement results of my own on this topic,
but my general understanding of the discussion in the IETF is that the
concern (i.e., the bad effects of dropping fragmented large packets)
is seriously taken.  One of the latest efforts in this sense is
draft-ietf-intarea-frag-fragile, which is currently in an intarea WGLC
and talks about DNS implications (btw, those who dismiss
atr-large-resp because the concern is FUD may want to comment on
intarea-frag-fragile too).  The research result cited in
draft-song-atr-large-resp
(https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns)
may still be anecdotal and artificial, but it also looks solid and
sufficiently broad to draw attention.  So I don't agree on dismissing
the work "because the problem doesn't exist".

I also don't agree on dismissing the work "because it's specific to
IPv6" (I don't know if it really is, but even if so), given the
commitment by the IETF to IPv6 deployment and related problems.

I see it's still debatable whether the particular proposal of "ATR" is
a good solution to the problem, however.  I admit that's a hack with
some obvious adverse effects such as increasing response traffic, so
if there's a better, cleaner solution, I'm happy to support that one
instead of ATR.  One aspect I like about ATR, however, is that it can
be deployed without changing resolvers.  In that sense I see it as
more promising compared to some other proposed DNS hacks, e.g., (the
ultimate form of) ANAME.

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

Re: [DNSOP] [v6ops] Fwd: New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

[神明達哉]

At Fri, 21 Sep 2018 14:31:50 +0800,
Davey Song  wrote:

> I just submited a new draft intending to provide better connectivity from
> network side function . Comments are welcome.

Some quick observations:

- I don't see why the intended status is Standards Track.  It seems to
  be a document about an operational practice rather than a new
  protocol feature.

- In general, I wouldn't be excited about placing such complicated
  functionality in the network rather than end hosts.  Sometimes it
  may be justified as a least evil option, but the current description
  of the draft didn't fully convince me

- I suspect the discussion on breaking DNSSEC is way too hand-waving.
  In my general understanding it's generally not accepted at dnsop to
  justify breaking DNSSEC just by saying "it's okay as validation at
  end hosts is not typical".  Especially if it really intends to be
  published as Standards Track I suspect some more detailed discussion
  with a stronger justification will be needed.

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

Re: [DNSOP] Minimum viable ANAME

[神明達哉]

At Fri, 21 Sep 2018 12:03:13 +0100,
Tony Finch  wrote:

> > Perhaps primary server implementations may eventually have some level
> > of support that makes this provisioning much less painful (in a way
> > other than performing on-demand resolution).  If and when many popular
> > implementations do it in a convenient way (at least as convenient as
> > the proprietary alternatives), we may hope the new model with ANAME
> > optimization will start to deploy, eventually with wider deployment of
> > the optimization part as more resolvers support it.
>
> It doesn't have to be sequential like that: the additional section
> processing on auth and rec servers, and resolver ANAME optimization won't
> cause any interop problems, so they can be deployed whenever the code is
> ready and they'll have a useful effect when they encounter an ANAME
> record.

It's true that "they (= additional section processing) can be deployed
whenever the code is ready".  But if I were a primary side admin who
wants to use an ALIAS-like feature, that wouldn't mean much
unless/until
A. the provisioning support in the primary server implementation is
   really convenient in terms of my operational costs, or
B. a significantly large number of resolvers support the additional
   section processing for ANAME

In my understanding of the discussion we all agree that it will take a
very long time until we have B.  So, in the end, the deployability
seems to depend on how soon we can have situation A and how convenient
the implementations are.  It may actually come quite soon and may
really become very popular.  I don't deny that possibility; I'm just
not personally so optimistic about it.

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

Re: [DNSOP] Minimum viable ANAME

[神明達哉]

At Wed, 19 Sep 2018 14:55:45 +0100,
Tony Finch  wrote:

> I think there's still a need to standardize ANAME, to provide at least
> some level of zone file portability between the various existing
> proprietary versions of this feature. And to provide something usable
> by zone publisters on a much shorter timescale than a nsa SRV-alike.
>
> So here's a sketch of a reduced ANAME:
>
> Primary servers / zone provisioning
> ---
>
> For each ANAME record, poll the target address records periodically
> (according to the relevant TTLs). When the target addresses don't
> match the owner's addresses, UPDATE the zone so they match.

I'm not sure how we can expect this model to deploy in practice.  With
this model, the zone admin will need to develop an additional script
or something integrated into whatever the provisioning framework they
are using.  Is that the assumption?

Then I suspect none of existing users of proprietary and
non-standard-compliant "ALIAS" will switch to it simply because it's
standard compliant.  And that will be also the case for those who now
want to start "aliasing at a zone apex".

Perhaps primary server implementations may eventually have some level
of support that makes this provisioning much less painful (in a way
other than performing on-demand resolution).  If and when many popular
implementations do it in a convenient way (at least as convenient as
the proprietary alternatives), we may hope the new model with ANAME
optimization will start to deploy, eventually with wider deployment of
the optimization part as more resolvers support it.  Perhaps that's
the intended deployment plan?  If so, I see some possibility there,
but I have to say I'm pessimistic about its reality.

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

Re: [DNSOP] Mirja Kühlewind's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

[神明達哉]

At Thu, 13 Sep 2018 17:25:04 +0200,
"Mirja Kuehlewind (IETF)"  wrote:

>>> I'm wondering if it would make sense to provide stronger guidance that
the
>>> conventional ANY response SHOULD be provided if TCP is used as TCP
already
>>> provides a retrun routability proof...? Also maybe provide a refernce to
>>> RFC7766?

>> This has nothing to do with "retrun routability"  if big answers
>> are given to resolver via TCP then the resolver can be used as
>> amplifier and there Millions of those on the net.

> With TCP you usually set up a TCP connection (3-way handshake) then
> send the request on that connection and get the reply on that
> connection. You can not change the IP address in the mean time. So
> there should not be that amplification attack anymore. That was what
> I was saying.

(I'm not intending to speak for him but) I guess what Ólafur intended
to say is that if a legacy (so not implementing dnsop-refuse-any) and
open resolver sends an ANY query over TCP and gets and caches the
large "conventional" response, that resolver can be exploited as an
amplifier for subsequent ANY queries with a forged source address (and
quite likely over UDP).  If so, that's true, but I don't think it
trivial to force such a resolver to send the ANY query over TCP in the
first place, and the argument against "a return of routability proof"
doesn't seem to be strong enough.  In fact, I'd interpret Section 4.4
of draft-ietf-dnsop-refuse-any-07 as it allows the conventional ANY
response over TCP exactly thanks to this return of routability proof
(this "responder" is much less likely to be exploited as an amplifier
thanks to that).  If the intent of this section has really nothing to
do with that, I'd like to see some explanation about the actual intent
in the document.

Whether we *SHOULD* (rather than MAY) allow the conventional response
in case of TCP is a different question, on which I don't have a strong
opinion.

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

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis

[神明達哉]

On Tue, Jul 24, 2018 at 9:33 AM Tim Wicinski  wrote:

>This starts a Call for Adoption for draft-bortzmeyer-rfc7816bis

>The draft is available here:
https://datatracker.ietf.org/doc/draft-bortzmeyer-rfc7816bis/

>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.

I support the adoption.  I'm willing to review future versions.

I have a couple of minor comments on 00:

- Regarding the first paragraph of Section 6, I've noticed RFC8198
  would have the same improvement effect.  You may or may not to
  mention it, but I'm noting it here as the draft also has a TODO
  about mentioning RFC8020 in this context.

- Also in Section 6:

   QNAME minimisation may also improve lookup performance for TLD
   operators.  For a typical TLD, delegation-only, and with delegations
   just under the TLD, a two-label QNAME query is optimal for finding
   the delegation owner name.

  It's not super obvious why it's "optimal".  Is this because it would
  be an exact match for minimized queries and the assumption is that
  an exact match is much more efficient than longest match in TLD
  server implementations?

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

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[神明達哉]

At Fri, 27 Jul 2018 16:43:44 -0400,
Warren Kumari  wrote:

> > Right, so I think one main question is why the root DNS zone case is
> > so special that a protocol extension is justified.  Personally, I'm
> > not yet fully convinced about it through the discussion so far.  As
> > several other people seem to be persuaded, however, maybe I'm too wary
> > just because of my hat of handling eventual "named triggers an
> > assertion failure after zone transfer for some bogus zone digest"
> > CVEs.  But at the same time, if my sense of the wg's take on the "DNS
> > camel" discussion is correct, I think we (WG) should require a higher
> > level of justification for new protocol features.
>
> This can, but does not have, to be built into the nameserver itself.

True, and I might feel much better if the draft said "name server
implementations MUST NOT compute or validate the zone digest
in their code":-).  More seriously, my concern with the "hat" wouldn't
be addressed simply because it can be implemented outside of a name server
implementation.  In fact, I can see it'll eventually be included in
code base I'll have to maintain if it's officially adopted and
published.  On the other hand, if we're okay with an out-of-band
implementation (independently from whether we like it in a name
server), then I guess it will become less distinguishable from
out-of-band digest approaches.  Either way it requires the operators
to use an additional tool, and it's therefore more operationally
costly, error prone, or easier to be ignored/forgotten.

--
JINMEI, Tatuya

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

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[神明達哉]

At Fri, 27 Jul 2018 10:59:53 +0800,
Davey Song  wrote:

> > The problem is that when you have every recursive server in the world with
> > a copy of the root zone from “random places” you want to reduce the
> > possible error spaces into manageable chunks when things go wrong which
> > they will.  Being able to verify the contents of the root zone you have are
> > not modified helps.
>
> Generaly speaking it is ture for any file replication. But it is not
> relevent with DNS context.

Right, so I think one main question is why the root DNS zone case is
so special that a protocol extension is justified.  Personally, I'm
not yet fully convinced about it through the discussion so far.  As
several other people seem to be persuaded, however, maybe I'm too wary
just because of my hat of handling eventual "named triggers an
assertion failure after zone transfer for some bogus zone digest"
CVEs.  But at the same time, if my sense of the wg's take on the "DNS
camel" discussion is correct, I think we (WG) should require a higher
level of justification for new protocol features.  Again, personally,
I don't yet think draft-wessels-dns-zone-digest has passed this test.

--
JINMEI, Tatuya

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

[DNSOP] comments on draft-pwouters-powerbind-01

[神明達哉]

I don't have a strong reason for opposing the proposal, but, frankly,
the need for this wasn't clear to me just by reading the draft.  I see
the potential problems with evil parents, but the draft didn't
convince me that it's an important and critical enough to justify a
new protocol extension (which made me recall the camel discussion),
not least because if the parent is malicious in the DNS then all bets
are off already.  If there's actually a consensus that this is an
important problem to solve, I wouldn't challenge that.  But it would
help newer/future readers if this doc explains the need more
specifically and in more detail.

It's also not clear how effective this is against the evil parent
tweaking the delegation (changing NS, e.g).  The draft seems to
try to address this point in a few places:

   [...] However, both
   of these actions cannot be hidden, thus exposing such malicious
   behavior when combined with public transparency logs.
[...]
   Replacing the NS and DS records of a child zone can still be done in
   a targetted attack mode, but these events are something that can be
   easilly tracked by a transparency infrastructure similar to what is
   now in use for the WebPKI using [RFC6962](bis).

but I was not sure why we can't also do this for the "deep link state"
problem (replacing a delegation with a parent's authoritative
record).  That's probably because I don't know much about the tracking
"by a transparency infrastructure".  In that case it might help if it
explains it in more detail.

I have a few more specific comments:

- I'd suggest making the requirement to validator implementations more
  explicitly:

   [...] if any such signed data is encountered by validating
   resolvers, that this data should be interpreted as BOGUS.

  Probably in a separate section like "Validator Behavior" rather than
  in Introduction, and maybe with an RFC2119 keyword.

- Section 3

   [...]  For example, the DNSSEC root key
   could ignore the NS records for ".org" and "example.org" and could
   place a record "www.example.org" directly into its own zone, with a

  "the DNSSEC root key could ignore..." doesn't make much sense to
  me.  Does this perhaps mean "the root zone could ignore..."?

- Section 4

   hierarchy.  This commits a parent in the DNS hierarchy to only sign
   NS and DS records (i.e. all non-glue, delegation records) for its
   child zones.

  Should this be "NSEC(3) and DS records"?

--
JINMEI, Tatuya

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

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

[神明達哉]

At Fri, 22 Jun 2018 16:00:51 -0400,
Paul Vixie  wrote:

> >> Minor clarification here: ANAME doesn't require the authoritative server
> >> itself to do recursion; it requires it to have access to a reursive
> >> server.
> >
> > I suppose, but that seems to me a distinction without a difference.
> > Either way we end up importing all of the failure modes of a recursive
> > server into an authoritative one.
>
> +1. authority servers cannot be coerce-able into doing work, whether
> it's computation, memory allocation, or external transactions like RDNS.

Also +1.  I've always thought there's no point in standardizing
ANAME-kind of thing unless its ultimate goal includes the
resolver-side support.  Of course it would take very long time and may
even turn out to be unsuccessful, but if we give up with the idea from
the beginning by stating 'not required, I wouldn't be able to support
the work.  So to me, this is not minor but quite critical.

--
JINMEI, Tatuya

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

Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

[神明達哉]

At Mon, 18 Jun 2018 17:51:26 -0400,
Shumon Huque  wrote:

> Client applications delegate address sorting to name resolution functions
> like getaddrinfo() - correct?
>
> Doing some quick tests of getaddrinfo() just now on a recent *NIX machine,
> it appears to return addresses sorted roughly in accordance with RFC
> 6724, but rule 9 (longest prefix match) seems to be only applied to
> IPv6 addresses. For IPv4 addresses (using an upstream resolver
> that randomizes the response RRset), the order returned by getaddrinfo()
> is ever changing - I assume presented in the order received.

The very original implementation of BSD getaddrinfo() conformed to the
RFC, but FreeBSD seems to have changed the behavior a few years ago so
rule 9 wouldn't apply to IPv4 addresses:
https://github.com/freebsd/freebsd/commit/1390d13ae69089142f6c6465dbb24438f295edee
The commit log suggests the rrset round-robin was exactly the
motivation for the change (whether it was good or bad).

--
JINMEI, Tatuya

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

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[神明達哉]

At Thu, 31 May 2018 18:18:16 +,
"Wessels, Duane"  wrote:

> > - This digest can't be incrementally updated, [...]
>
> Incremental updates could be supported if the working group feels it is
> important.  We have a working proof-of-concept implementation of this that
> hashes individual RRsets and then XORs them into a final message digest
> (thanks to Roy Arends for the suggestion).

It's just an observation, not a blocking issue.  But I think it's
worth discussing in the WG if and when this document is adopted.

> > Specific comments:
> >
> > - Section 4.1
> >
> >This specification adopts DNSSEC's canonical ordering for names
> >(Section 6.1 of [RFC4034]), and canonical ordering for RRs within an
> >
> >   This means upper case letters in owner names are converted to lower
> >   case ones.  It could be considered a feature, but I guess some
> >   operators might want to check integrity including letter case of
> >   names.  For example, recent versions of ISC BIND 9 tries quite hard
> >   to preserve the letter case of owner names per RRset basis, which I
> >   think suggests operator needs for preserving the case as much as
> >   possible.
>
> We do not propose that owner names be permanently converted.  DNSSEC has this
> same characteristic, does it not?  The validator canonicalizes the owner names
> upon validation, but does not cache them canonicalized.

Perhaps I wasn't clear.  What I tried to say is that we can't notice
that using this digest if 'WWW.EXAMPLE.COM. IN  2001:db8::1' is
magically changed to 'www.example.com. IN  2001:db8::1' in the
zone.  This is also slightly related to the "problem statement".  If
the digest can detect this kind of change, it will be another new
feature that DNSSEC-based integrity check can't detect.  Of course,
whether we want this feature is a different question.  I wonder there
might be a need for this by referring to the BIND 9 changes, but I
don't know if it's real or just imaginary.

> > - Section 4.4
> >
> >The zone digest is calculated by concatenating the canonical on-the-
> >wire form of RRs in the zone, in the order described above, subject
> >to the inclusion/exclusion rules described below, and then applying
> >the digest algorithm:
> >
> >   I wonder whether glue records are included in these RRs.  Either
> >   way, it would be better to clarify the point.
>
> If we say "calculated by concatenating ... all RRs in the zone" is that 
> sufficient?

I'd be even more explicit, like 'all RRs in the zone including glue
records' or 'all RRs in the zone including those on and below a zone
cut'.

BTW, there may be some interesting corner cases related to this point.
If we configure the 'example.com' zone with the following records:

d.example.com. IN DNAME d.example.org.
a.d.example.com. IN  2001:db8::1

then, should the  record be included in the digest?  BIND 9
doesn't consider it an error, does load it into memory and transfer it
via AXFR, and, IIRC, would use it to answer queries if the DNAME is
removed via DDNS or IXFR.  So this question has a practical
implication at least for such an implementation.

--
JINMEI, Tatuya

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

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[神明達哉]

At Wed, 23 May 2018 15:32:11 +,
"Weinberg, Matt" 

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

[神明達哉]

At Wed, 23 May 2018 14:39:40 -0400,
Warren Kumari  wrote:

> Just so the WG knows, the authors (myself in particular) had some
> productive discussions with Job at the RIPE meeting in Marseille.

> As a reminder, this mechanism is designed to measure the *user* impact of
> the KSK roll - this means that querying the first resolver in e.g:
> resolve.conf, getting SERVFAIL and then failing over to the second (or
> third or n-th) until a response is received is fine, and expected.

> The document currently contains:
[...]
> "Note that a slew of other issues can also cause SERVFAIL responses, **and
> so the sentinel processing may sometimes result in incorrect
> conclusions.**" (emphasis added).

> An example of a case where an incorrect conclusion could occur is if the
> client is using an Anycast recursive resolver (e.g: 8.8.8.8) and some of
> the backends of that Anycast network have only the old key, and some have
> the new key, and ECMP directs you to different backend. Another exmaple is
> if the resolver learns the new key *during* a clients testing. To me these
> feel like pathological cases, and are covered by "may sometimes result in
> incorrect conclusions".
> Does the WG feel that this is sufficient, or would it like additional
text?
> If so, can you propose some?

I don't have a strong opinion on the main question (I'm fine with the
current version of this draft regarding this matter).  But I'd like to
point out that the above quoted text regarding SERVFAIL and "incorrect
conclusions" (which I think I proposed before) mainly concerned cases
where SERVFAIL is returned for a different reason than the one
described in kskroll-sentinel such as query timeout (note the "other
issues" in the text).  Likewise, "incorrect conclusions" mainly
intended such cases as deducing Vnew/Vold/Vleg labels while the
corresponding SERVFAIL was returned for a different reason.  I think
it's slightly different from a type of "incorrect conclusions"
discussed in this thread, since an incorrect conclusion is reached not
because SERVFAIL is returned for a different reason but because it's
inconsistent which server sends which.

Again, I'm fine with the current text anyway.  But if we want to tweak
the text in response to the concern in this thread while preserving
the original text quoted above, then we might say something like:

OLD
[...] Note that a slew of other issues can also cause SERVFAIL
responses, and so the sentinel processing may sometimes result in
incorrect conclusions.

NEW
[...] Note that a slew of other issues can also cause SERVFAIL
responses and DNS transactions are not always reliable or
consistent, and so the sentinel processing may sometimes result in
incorrect conclusions.

--
JINMEI, Tatuya

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

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

[神明達哉]

At Tue, 22 May 2018 13:50:20 +0100,
Neil Cook  wrote:

> I’m wondering what the status of this draft is? It expired in
> September last year. Is there still a desire to get this pushed
> through?

At least I (and my employer, Infoblox) are interested.  The business
motivation aside, I've seen several different variants of this option
already deployed in the field with different EDNS option codes and
conformance to draft-tale-dnsop-edns0-clientid.  It would be a pity
if we can't provide a unified protocol specification to ensure
interoperability.

> We (i.e. Open-Xchange/PowerDNS) are really interested in seeing this
> become a standard, and personally I’d be happy to take over
> authorship and drive it through if necessary, but I’m not exactly
> sure why it died - was there lack of consensus for this, or did it
> just fall through the cracks?

I talked to Dave Lawrence at the London IETF meeting in March
regarding the status of the draft.  If I understood it correctly there
was previously some pushback and that was one main reason why the
progress has stalled (Dave may correct me if my understanding is
wrong).  I certainly see some concerns, most notably privacy
implications, but I think these can be addressed through discussion.

As for authorship, we might ask Dave.  He seemed to still have a
motivation in March, but perhaps he's too busy to resume the effort.
Hopefully he can respond on this list whether it's okay for some other
co-editors to join.

I support resuming the effort, and if it's resumed I'm happy to review
it.  If it's necessary I'm even willing to help edit the draft either
as another co-editor or as a serious contributor.

--
JINMEI, Tatuya

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

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

[神明達哉]

At Fri, 13 Apr 2018 16:47:07 +0200,
bert hubert  wrote:

> In writing this server and while consulting with some other implementors, I
> for now have decided that in 2018 it makes no sense to:
>
> 1) chase CNAMEs that point to another zone

It may not even make sense to chase CNAME in the same zone, since the
receiving resolver generally can't be sure if it's really in the same
zone and would need to chase it by itself anyway.

When a resolver receives this from an 'example.com' authoritative server:
alias.example.com. CNAME cname1.example.com.
cname1.example.com.  2001:db8::1

It might look cname1.example.com. is actually in the
example.com. zone, but the resolver can't be 100% sure about it unless
it also knows cname1.example.com. is on a zone cut.  And, in my
understanding, today's deployed resolvers actually chase
cname1.example.com./ by itself.  So the  added by the
authoritative server would effectively be a waste.

(If the zone is DNSSEC signed and the authoritative server can include
DNSSEC proofs of the RRsets in the chain, the story may become
different.  But I don't think we are discussing such an "advanced"
case).

--
JINMEI, Tatuya

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

Re: [DNSOP] Call for Adoption: draft-dupont-dnsop-rfc2845bis

[神明達哉]

At Tue, 10 Apr 2018 14:56:53 -0400,
tjw ietf  wrote:

> This draft was widely accepted in Singapore, and the chairs were waiting for
> a revision before starting a call for adoption. That revision took a few
> months
> but it has been done and DNSOP is ready to start a call for adoption.
>
> This draft addresess the bug found in the existing RFC.
>
> This starts a Call for Adoption for draft-dupont-dnsop-rfc2845bis
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-dupont-dnsop-rfc2845bis/
>
> 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.

I support the adoption.  I've already reviewed the draft and provided
(minor) feedback:
https://www.ietf.org/mail-archive/web/dnsop/current/msg22063.html

--
JINMEI, Tatuya

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

Re: [DNSOP] raising the bar: requiring implementations

[神明達哉]

At Fri, 6 Apr 2018 04:35:44 +,
Evan Hunt  wrote:

> > At Thu, 5 Apr 2018 13:46:29 -0400,
> > tjw ietf  wrote:
> >
> > > What is work: An "informational" document being used as standard is people
> > > taking a submitted (expired) draft as "standard"?
> >
> > I'm not sure how to interpret it (not even sure if it's a question to
> > me)...
>
> I suspect Tim meant to type "What is worse: An 'informational' document
> being used as standard, or people taking a submitted (expired) draft as
> 'standard'?"

Ah, okay, it makes sense, thanks.  (Correcting this was far beyond my
ability of dealing with the language of English:-).  I still don't
know if it was meant to be a counter argument to my previous message
or an unrelated followup, but in any case that's a different topic
than my main concern.  This is much closer to the point:

> ECS, though, was published before it was fully cooked, and continuing to
> iterate and update the drafts would've been better.

and, at least in retrospect, my observation was that the intended
informational status was (ab)used to have this result, and IMO we
should be careful not to repeat it.

--
JINMEI, Tatuya

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

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

[神明達哉]

At Thu, 05 Apr 2018 17:15:47 +,
Job Snijders  wrote:

> While the chair notes awareness of the point I raised, I’d like the be
> explicit to avoid any confusion.
>
> This document is *not* ready for publication. There is no implementation
> report available for review and consideration.

(After reading other messages in this thread) I tend to agree.  Even
after careful reviews of protocol text, an attempt of actually
implementing it often reveals non-negligible issues that were
overlooked in the review.  Of course, it's a different question
whether dnsop adopts the requirement as a general rule for any
documents (although I would support the idea personally), at least in
this particular case I think it makes sense because:
- right now there's no known implementation of the latest version of
  the draft
- there seems to be some reasonable expectation that Knot will support
  the latest version not far from now
So it makes sense to me to hold off at least until Knot (or any other
implementation) actually adds
support for it or a sufficient amount of time (a couple of weeks?)
elapses without a news.  In the latter case we might discuss whether
we should make a compromise to move forward at that point.

--
JINMEI, Tatuya

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

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[神明達哉]

At Tue, 3 Apr 2018 21:32:04 +,
"Wessels, Duane"  wrote:

> This draft proposes a technique and new RR type for calculating and
> verifying a message digest over the contents of a zone file.  Using
> this technique, the recipient of a zone containing the new RR type
> can verify it for completeness and correctness, especially so when
> the zone is signed.  We welcome your feedback on this document.

FWIW, I came up with a similar idea and implemented a patch to ISC
BIND 9 as a kind of hobby project.  It's available at:
https://github.com/jinmei/bind9-zonecksum/tree/zonesum
although it doesn't have a way to publish the digest in the form of RR.

And so, obviously, I like the basic idea of the draft:-)

--
JINMEI, Tatuya

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

Re: [DNSOP] raising the bar: requiring implementations

[神明達哉]

At Thu, 5 Apr 2018 13:46:29 -0400,
tjw ietf  wrote:

> What is work: An "informational" document being used as standard is people
> taking a submitted (expired) draft as "standard"?

I'm not sure how to interpret it (not even sure if it's a question to
me)...but I guess what I think is the most important point of my
previous message is "for future dnsop documents, we shouldn't use the
intended informational status as an excuse to casually dismiss serious
questions/suggestions from implementers".

--
JINMEI, Tatuya

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

Re: [DNSOP] raising the bar: requiring implementations

[神明達哉]

At Wed, 4 Apr 2018 11:22:33 +0200,
Petr Špaček  wrote:

> >> This is actually quite a good example of another problem:
> >> Client-subnet was documented for Informational purposes; it was
> >> already in wide use in the public internet and had an EDNS opt code
> >> codepoint allocated from the IANA registry.
> >>
> >> Nothing that happened in DNSOP or the IETF changed that, and I
> >> strongly suspect nothing that happened in DNSOP or the IETF could have
> >> changed it.
> >
> > We found issues in the client-subnet description (in the draft stages)
> > that were corrected before it became RFC - this involved some behavioral
> > changes. However, the opportunity was not given to address fundamental
> > design issues, so what's in the RFC largely documents the
> > implementations preceding it and still has issues. I didn't think
> > client-subnet was in wide use when it came to dnsop. Even today it
> > doesn't look like it's in wide use.

[...]

> I tend to agree with Mukund. What's the point of doing standards, if
> there is nothing to test against?

I also agree here.  Especially in the case of client-subnet, I
observed another (IMO) bad practice that seems to be abused quite
often recently: use the word of "informational" as an excuse for
dismissing suggestions.  The commonly seen logic is "this is just
intended to be an information document, just describing an existing
deployment in case that may be useful for others (and so any
significant changes should be rejected)".  But in actuality such a
spec is often used as a standard protocol spec that should be
interoperable among various different implementations.  And, IMO, that
was actually the case for ECS.

Another rhetoric often (ab)used in such a case is to say "a more
complete full standard will follow this informational document; we can
make significant changes at that point."  But in reality such a
followup task often doesn't even start.  Again, that's also the case
for ECS after nearly two years since the publication of RFC7871.

In the context of the camel discussion, I think we should use this
lesson for rejecting this kind of abusing the "informational" status.
We should not pretend it's really just for information when we
actually expect it will be used a "de facto" standard that is likely
to be implemented by various vendors.

--
JINMEI, Tatuya

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

Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

[神明達哉]

At Sat, 10 Mar 2018 21:56:15 +0530,
Mukund Sivaraman  wrote:

> > I've read draft-muks-dnsop-dns-catalog-zones-04.  I see the motivation
> > of automating the synchronization of primary/secondary configurations.
> > Personally, however, I'm not (yet?) convinced that this should be
> > "standardized" in the form of an RFC or that this should be done
> > through another tricky use of DNS.  One big reason for standardization
> > is to have a unified way that is interoperable with multiple different
> > vendors.  But when it comes to configuration, difference on
> > vendor-specific options often matters, and unless the common basic set
> > of configuration is sufficiently common, a generic and interoperable
> > mechanism will be useless.  I'm not yet convinced about it regarding
>
> Some background of how/why catalog zones feature in BIND 9.11 and the
> draft came to be is that we often got feedback about requiring better
> ways to provision zones and content on multiple nameservers, and
> different operators had different ideas about it. They wanted to improve
> performance, reduce the scope for mistakes, and have a method that
> worked across implementations.

I can understand that, and, if it mainly means different versions of
BIND, that's certainly possible.  If it also means a unified way that
works for multiple different vendors, I personally doubt it's
feasible; I suspect those operators assume some kind of magic happens
in the unified mechanism and gracefully handle differences in config
details amount different vendors' implementations, and would complain
when they realize it doesn't work that way.  So...

> The draft as it stands provides a way to specify config options within
> the zone, but does not specify an explicit list of options. There is no
> enthusiasm among the authors to do so in this draft.

...I'm personally not convinced this proposal will be useful as an
interoperable way to solve the issue (but, of course, it may be a good
idea as an enhancement to BIND) unless you actually address this
point.

That said,

> > this proposal.  (in that sense, I'm curious: is there other DNS
> > developer than ISC that is interested in implementing this proposal?)
>
> So far: I was told that PowerDNS has implemented a plug-in/script that
> provides support for catalog zones.

if there is actually an interest (or better, implementation or
deployment cases) in having an interoperable way of synchronizing
primary/secondary meta info, it may become more convincing.  I'd
suggest you confirming the rumor and including the implementation
status in the draft.

--
JINMEI, Tatuya

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

Re: [DNSOP] meeting agenda?

[神明達哉]

Thanks, I'm looking forward to seeing it:-)

On Fri, Mar 9, 2018 at 11:05 AM, Tim Wicinski <tjw.i...@gmail.com> wrote:
>
> Hi
>
> I have one and was waiting for Suzanne to land in Puerto Rico and we can
> confirm but you should see that soon enough.
>
> thanks!
> tim
>
>
> On 3/9/18 14:03, 神明達哉 wrote:
>>
>> dnsop meeting agenda hasn't yet been uploaded on
>> https://datatracker.ietf.org/meeting/agenda.html
>>
>> Is there at least an unofficial meeting agenda so we can have more
>> specific idea of what will be discussed?
>>
>> Thanks.
>>
>> --
>> JINMEI, Tatuya
>>
>> ___
>> 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

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

[DNSOP] meeting agenda?

[神明達哉]

dnsop meeting agenda hasn't yet been uploaded on
https://datatracker.ietf.org/meeting/agenda.html

Is there at least an unofficial meeting agenda so we can have more
specific idea of what will be discussed?

Thanks.

--
JINMEI, Tatuya

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

Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

[神明達哉]

At Sat, 3 Mar 2018 22:07:57 +,
Ray Bellis  wrote:

> > Abstract: This document describes a method for automatic DNS zone
> > provisioning among DNS primary and secondary nameservers by storing
> > and transferring the catalog of zones to be provisioned as one or
> > more regular DNS zones.
>
> This version of the Catalog Zones draft has undergone significant
> restructuring, in particular to separate out the mechanism by which
> single-valued and multi-valued properties are specified.

I've read draft-muks-dnsop-dns-catalog-zones-04.  I see the motivation
of automating the synchronization of primary/secondary configurations.
Personally, however, I'm not (yet?) convinced that this should be
"standardized" in the form of an RFC or that this should be done
through another tricky use of DNS.  One big reason for standardization
is to have a unified way that is interoperable with multiple different
vendors.  But when it comes to configuration, difference on
vendor-specific options often matters, and unless the common basic set
of configuration is sufficiently common, a generic and interoperable
mechanism will be useless.  I'm not yet convinced about it regarding
this proposal.  (in that sense, I'm curious: is there other DNS
developer than ISC that is interested in implementing this proposal?)

I'm also not convinced that using standard DNS RRs is the best way to
implement the idea.  I see the advantage of it (most notably the
ability of synchronization via zone transfer), but various limitations
of the DNS protocol also make it unnecessarily complicated.  The issue
regarding DNAME is one example.  The way to implement the multi-valued
properties seems to be another.  I'm not convinced the advantages
obviously outweigh drawbacks.

Anyway, I have some comments on the draft body, below:

- Section 4.2.1

   NB: Catalog zones use some RR TYPEs (such as PTR) with alternate
   semantics to those originally defined for them.  Although this may be
   controversial, the situation is similar to other similar zone-based
   representations such as response-policy zones [RPZ].

  I think this justification is weak.  As this text seems to imply,
  I believe everyone agrees that (ab)using standard RRs for a
  different semantics in RPZ is controversial.  Perhaps in the case of
  RPZ a sufficiently large number of people accept it for reasons
  including inertia.  But I don't think a precedence of one
  controversial approach automatically justifies another controversial
  one simply because they are similar.  IMO the new one should have its
  own justification.

- Section 4.2.1

   It is an error for any single owner name within a catalog zone (other
   than the apex of the zone itself) to have more than one RR associated
   with it.

  It was not clear to me why this restriction was necessary, at least
  at the point of reading this text.  I guess this may be related to
  the ordering of ordered multi-valued properties, but I'm still not
  really sure about it.  It would be nice if it's clarified in more
  detail.

  Also, it's not clear what "error" means here.  Does that mean, for
  example, loading the zone should be refused if it violates this
  restriction?  I think this should be clarified.

- Section 4.3.4: minor typo, s/the the/the/

   specifying the property under the the sub-domain associated with the

- Section 5.1: s/the MUST/they MUST/ ?

   If the RDATA is split into multiple  elements the
   MUST be directly concatenated without any separating character.

--
JINMEI, Tatuya

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

[DNSOP] comments on draft-dupont-dnsop-rfc2845bis-01

[神明達哉]

I have a couple of high-level comments on rfc2845bis-01:

- Section 11.1 and Appendix B says "the MAC must be considered to be
  invalid until it was validated".  This is fine, but it was not
  immediately clear to me specifically how RFC2845 was updated based
  on this principle until I actually compared the RFC and the draft
  closely and found the key difference in the "Sever TSIG checks"
  section:
  RFC2845:
   [...]  The server MUST perform the following checks in the
   following order, check KEY, check TIME values, check MAC.

  rfc2845bis-01:
   [...]  The server MUST perform the following checks in the
   following order, check Key, check MAC, check Time values, check
   Truncation policy.

  I suggest clarifying the relationship between the principle and the
  actual protocol change either in Section 11.1 or in Section 6.5, or
  in both.

- Regarding the author list (noted in Appendix B):

  Authors of original documents were moved to Acknowledgments
  (Appendix A).

  if not done yet, I suggest contacting the authors of the previous RFCs to
  confirm this is okay.  Previously I experienced a case where an
  author of the original RFC was not comfortable with being removed
  from the author list in a bis doc.

And, one minor typo in Section 4.3:

 *  Time Signed - the The Time Signed field specifies seconds
since 00:00 on 1970-01-01 UTC.

'The' should be removed.

--
JINMEI, Tatuya

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

Re: [DNSOP] Updated KSK Sentinel document

[神明達哉]

At Wed, 21 Feb 2018 08:53:23 -0500,
Warren Kumari  wrote:

> > - General
> >   I think it's worth pointing out that SERVFAIL can be returned for
> >   various other reasons and the detection mechanism relying on it
> >   isn't reliable.  This is probably okay given the purpose of this
> >   detection, but I think it's better to note it explicitly.
>
> Good point. I had some trickiness writing this - how is "The
> techniques describes in this document rely on (DNSSEC validating)
> resolvers responding with SERVFAIL (RCODE 2) to valid answers. Note
> that a slew of other issues can also cause SERVFAIL responses, so
> false positive or negative results may sometimes occur." ?

Works for me, except that I might avoid 'false positive/negative' as
it's often ambiguous or confusing (exactly what "false positive" means
depends on the context).  I'd personally say something like "..., so
the sentinel processing (Section 4) may sometimes result in incorrect
conclusions".  But that's probably minor in the entire context of this
document, so I'd leave it to you.

> > - Section 3
> >
> >[...]  Note
> >that the  is specified in the DNS label using hexadecimal
> >notation.
> >
> >   I suggest clarifying whether '' contains leading 0s
> >   somewhere in the document (this may not be the best place to do so,
> >   but this is the first reference to 'tag-index' that made the
> >   question occur to me).
>
> Hmmm... Good point. I personally actually preferred having these as
> "decimal" keys.
> RFC1034, Sec 5.3: The DS RR Presentation Format sayeth:
>" The Key Tag field MUST be represented as an unsigned decimal
> integer.", things like dig +multiline DNSKEY . shows it as decimal,
> etc.
> My initial demos (www.ksk-test.net) also all used decimal. Petr
> recently pointed out to me that I'd messed up, and so I converted my
> demo to use hex, as the draft states.
> What does the WG prefer? Is the new KSK called "20326" or it is "4f66"?
>
> Note that Knot Resolver 2.1  already implements (thank you!) this, and as hex.
> But, yes, either way, we need to note if it is padded.
> [TODO(WK): Raise the hex vs Dec issue]

Personally I don't have a strong opinion/preference on hex vs decimal
or with or without leading zeros as long as it's clearly specified.
But I see the point of preferring the decimal representation you
showed above.  https://data.iana.org/root-anchors/root-anchors.xml
also uses the decimal representation, so especially if we expect the
usage of this query by a human operator who builds the query name by
hand, it would be more convenient if it's consistent with other common
representations, which is currently decimal.  But again, I don't have
a strong opinion.

> > - Section 3
> >
> >If the resolver has not placed a
> >Root Zone Key Signing Key with tag index value matching the value
> >specified in the query into the local resolver's store of trusted
> >keys, then the resolver should return a response indicating that the
> >response contains authenticated data according to section 5.8 of
> >[RFC6840].
> >
> >   Should we perhaps define "store of trusted keys" more precisely?
> >   For example, if a key is in the "AddPend" status (per RFC5011) for
> >   the resolver, should it be considered in the "store of trusted
> >   keys"?
>
> Nope. Well, yes, we need to better define it, but no, a key in AddPend
> is not considered.
> We explicitly mean "keys which are active and can be used for
> validating entries in the root zone."

To be clear, I didn't think a key in the "AddPend" state is considered
to be in the "store of trusted keys".  I just pointed out that it may
not be super clear.  And so...

> We have: "In particular, this response mechanism can be used to
> determine whether a certain Root Zone KSK is ready to be used as a
> trusted key within the context of a key roll by this resolver."
> and I added:
> "An active key is one which could currently be used for validation (ie
> not in AddPend or Revoked state (RFC5011)).
>
> Sounds reasonable?

yes it does.

> >   BTW, you might want to say 'a query for an Address Record' or 'an
> >   Address Record query' instead of 'an A or  query' (I guess
> >   that's the intent of the introduction of this term.  See also my
> >   first comment on Section 1.1 above).
>
> Actually, there are small enough number of occurrences that explicitly
> listing them (and not creating a new term) seemed better, so (see
> ablove) I removed the "Address Record" term and left in the "A or
> " stuff - please let me know if you agree.

Works for me.

--
JINMEI, Tatuya

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

Re: [DNSOP] Updated KSK Sentinel document

[神明達哉]

At Mon, 12 Feb 2018 15:28:50 -0500,
Warren Kumari  wrote:

> Anyway, we've finally posted an updated version -
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/

I've read draft-ietf-dnsop-kskroll-sentinel-01 (this is my first
careful read of this draft) and found it generally well-written.

I have some comments on 01.  These are basically editorial.

- General
  I think it's worth pointing out that SERVFAIL can be returned for
  various other reasons and the detection mechanism relying on it
  isn't reliable.  This is probably okay given the purpose of this
  detection, but I think it's better to note it explicitly.

- Section 1.1
   Address Record: Throughout this document we use the term Address
   Record (AR) to mean an A or  record.  [...]

  I actually didn't find this term other than here and Section 9
  (change log).

- Section 1.1 and throughout the draft

    records and the IPv6 documentation prefix (2001:DB8::/32) as

  I'd suggest using lower-case letters to show IPv6 addresses and
  prefixes, following the recommendation of RFC5952.  It's not a big
  deal but it would be better if we can be more consistent on the
  choice of letter case in RFCs.

- Section 2

   Charlie's resolvers are validating, but they have not been upgraded
   [...]
   resolve it).  He is able to fetch both of the other resources - from
   this he knows (see the logic below) that he is using legacy, non-
   validating resolvers.  [...]

  Do you mean "he is using legacy validating resolvers"?  If it's not
  a typo, the behind logic isn't obvious to me and it would help if
  you explain it in more detail (instead of just referring to
  'below').

- Section 3

   [...] Note that
   the test is "Is there a key with this KeyID in the resolver's current
   trust store for the DNS root", not "Is there any key with this KeyID
   in the trust store", nor "Was a key with this KeyID used to validate
   this query?".

  Unless I miss something, the draft doesn't clarify its use is
  limited to root KSK until the next paragraph of this, so I suspect
  this statement will confuse a fresh reader who reads this doc from
  top to bottom without a particular knowledge of background
  discussion.  I'd suggest noting it somewhere before this part,
  perhaps in the introduction (and maybe also in abstract).

- Section 3

   [...]  Note
   that the  is specified in the DNS label using hexadecimal
   notation.

  I suggest clarifying whether '' contains leading 0s
  somewhere in the document (this may not be the best place to do so,
  but this is the first reference to 'tag-index' that made the
  question occur to me).

- Section 3

   If the resolver has not placed a
   Root Zone Key Signing Key with tag index value matching the value
   specified in the query into the local resolver's store of trusted
   keys, then the resolver should return a response indicating that the
   response contains authenticated data according to section 5.8 of
   [RFC6840].

  Should we perhaps define "store of trusted keys" more precisely?
  For example, if a key is in the "AddPend" status (per RFC5011) for
  the resolver, should it be considered in the "store of trusted
  keys"?

- Section 3

   This mechanism is to be applied only by resolvers that are performing
   DNSSEC validation, and applies only to RRset responses to an A or
    query (Query Type value 1 or 28) where the resolver has
   authenticated the response RRset according to the DNSSEC validation
   process and where the query name contains either of the labels
   described in this section as its left-most label.

  Is the RRset in 'response RRset' intentionally added (or in other
  words can't it just be 'response')?  Perhaps is the intent to
  exclude negative responses?  In any case I think the intent should
  be clearer here.  And if a mere 'response' suffices it's probably
  less confusing to just say so.

  BTW, you might want to say 'a query for an Address Record' or 'an
  Address Record query' instead of 'an A or  query' (I guess
  that's the intent of the introduction of this term.  See also my
  first comment on Section 1.1 above).

- Section 4

   o  Vleg: A DNSSEC-Validating resolver that does not implement this
  mechanism will respond with an A or  RRSET response for
  "kskroll-sentinel-is-ta", an A record response for "kskroll-
  sentinel-not-ta" and SERVFAIL for the invalid name.

  + s/RRSET/RRset/?
  + 'an A record response' should be 'an A or  record response' or
it's revised using the "Address Record" term.  Same comment
applies to other part of this section including the table.

--
JINMEI, Tatuya

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

Re: [DNSOP] meaning of tag "match" for CAA RDATA

[神明達哉]

At Thu, 8 Feb 2018 08:25:35 +1100,
Mark Andrews  wrote:

> > I happen to have this question while reading RFC6844: what does the
> > "matching" mean in the following description of Section 5.1?
> >
> >   Tag:  The property identifier, a sequence of US-ASCII characters.
> >
> >  Tag values MAY contain US-ASCII characters 'a' through 'z', 'A'
> >  through 'Z', and the numbers 0 through 9.  Tag values SHOULD NOT
> >  contain any other characters.  Matching of tag values is case
> >  insensitive.
[...]
> > Does this mean, for example, we should perform case-insensitive
> > comparison of this field when we compare CAA RDATAs?  (If so, at least
> > ISC BIND 9 isn't compliant to the spec; it doesn't care about the case
> > of the tag field when loading or serving or updating or signing a CAA
> > RR).
>
> Why should it care about the case? ABC is different to abc as far as
> DNSSEC and handling of unknown record types is concerned.  A signer
> that is CAA aware could remove “duplicates” that differ in the case
> of this field but nothing else can.

I didn't intend to say it (DNS implementation) should care about the
case.  My point (or question) was the RFC text can be ambiguous.  On
re-reading RFC3597 I now see it would clearly violate Section 6 of
RFC3597:

   specifications for new RR types MUST NOT specify
   type-specific comparison rules.

if it meant case-insensitive RDATA comparison.  But the current text
of RFC6844 made me think whether the RFC erroneously violated it or it
meant something else.  It would have been clearer if "Matching of tag
values is case insensitive" were somewhere after Section 5.1, or at
least it explicitly said this is about CAs that use the CAA, not for a
DNS implementation.

I'd also wonder what the "Canonical Presentation Format" means then:

   Tag:  Is a non-zero sequence of US-ASCII letters and numbers in lower
  case.

so, for example, we can't always safely dump a validly loaded zone
containing CAA whose tag has an upper-cased letter into a file in the
"canonical presentation format" and then re-load it, since the dump
can result in false duplicates.

...and now I see there was almost exactly the same discussion about 2
years ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16810.html

Perhaps it's pretty clear that the current text of RFC6844 is very
confusing (if not wrong) and worth some errata again?

--
JINMEI, Tatuya

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

[DNSOP] meaning of tag "match" for CAA RDATA

[神明達哉]

I happen to have this question while reading RFC6844: what does the
"matching" mean in the following description of Section 5.1?

   Tag:  The property identifier, a sequence of US-ASCII characters.

  Tag values MAY contain US-ASCII characters 'a' through 'z', 'A'
  through 'Z', and the numbers 0 through 9.  Tag values SHOULD NOT
  contain any other characters.  Matching of tag values is case
  insensitive.

Although the boundary is not very clear, Section 5.1 generally seems
to talk about the DNS-level syntax (e.g. what should/should not appear
in wire as a DNS message or in a zone file), while Section 5.2 and
later mainly talk about the semantics at the application layer
(something that validates certificates).  Since the above text is in
Section 5.1, I first thought "matching of tag values" was a DNS level
concept.  But then it's not clear to me what it actually means.

Does this mean, for example, we should perform case-insensitive
comparison of this field when we compare CAA RDATAs?  (If so, at least
ISC BIND 9 isn't compliant to the spec; it doesn't care about the case
of the tag field when loading or serving or updating or signing a CAA
RR).

It may also be related to Section 5.1.1, which states:

   The canonical presentation format of the CAA record is:

   CAA   
[...]
   Tag:  Is a non-zero sequence of US-ASCII letters and numbers in lower
  case.

which might read, for example, as 'dig' should present the tag field
with lower-case letters.  But 'dig' currently doesn't work that way.

Could someone more familiar with the background of CAA clarify these
points?

Thanks,

--
JINMEI, Tatuya

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[神明達哉]

At Fri, 26 Jan 2018 14:24:10 -0500,
Ted Lemon  wrote:

> > IMO, however, that doesn't mean we can casually use the fact to
> > silence objections when the requirement level might actually be too
> > strong.  In my understanding and also according to my experiences,
> > MUST requirements are in fact very strong.
>
> Can you talk about why you personally think MUST is too strong here?

I said it might be too strong, so it's more that I *wonder* whether it
might be too strong.  This impression comes from the observation that
while the draft uses a strong word several people hinted at
customization.  That looked odd to me - if they so strongly think it
must be a MUST, it would look more sensible to me if they said "it
MUST be that way, period ".  It's true that there are
always people who still disagree with it and are willing to ignore the
MUST, but in that case we should rather call them a standard offender
instead of pretending to offer an option.  Stating a MUST on one hand
while hinting at violating it as a "customization" on the other looked
awkward to me, making me think the WG might actually feel it's too
strong.

> It's interesting to discuss it on a meta-level, but I think we might
> get lost in the weeds doing that.   If you are feeling uneasy about
> this requirement, I suspect that there is a use case lurking down
> there somewhere under the discomfort.   Bringing it up to the
> surface might help.

Personally, I don't mind the MUST (and for that matter I don't mind
either if it's a SHOULD).  But given that it will break existing
practices, I'd like the draft to explain the rationale in more detail.
And I'd like it to make it clearer that it intentionally plugs any
possibility of user customization, whether it's a protocol-violating
server option or a customized /etc/hosts entry.  And then let the
market decide whether to obey it.

As for specific use case, I don't have one for myself as such.  But
the discussion so far (not only in this thread but also in the past WG
discussions, which actually are the base of my own response to the LC)
seems to suggest that a non-negligible number of deployments exist.
And I just thought the current content of the draft isn't clear enough
as a message for those with the existing deployments.

BTW: in case you think if I personally don't mind I should shut up: I
observed this oddity as a weakness of the document that could make it
less convincing and more likely to be ignored.  I believe pointing it
out and possibly improving it are completely valid feedback for a
WGLC, regardless of my own personal position on the content.  Of
course, whether and how to address the feedback is up to the WG; I'm
not intending to be a blocker but are just trying to help it.

--
JINMEI, Tatuya

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[神明達哉]

At Thu, 25 Jan 2018 20:22:36 +,
Tony Finch  wrote:

> > Could you be more specific about it?  It may be a minority
> > implementation, but I thought traditional stub resolver
> > implementations in BSD variants systems (getaddrinfo/gethostbyname
> > with the backend of libresolv) didn't hardocde special logic for
> > "localhost." yet.  It's true that such implementations refer to
> > /etc/hosts and it has system-installed mapping between 'localhost.'
> > and ::1 by default.  Do you mean (in addition to hardcoding the
> > special logic) this kind of combination of generic implementation with
> > default system configuration?
>
> Exactly, yes.

Okay, then would such a system be deemed to conform to this part of
the draft?

   3.  Name resolution APIs and libraries MUST recognize localhost names
   as special, and MUST always return an appropriate IP loopback
   address for IPv4 and IPv6 address queries and negative responses
   for all other query types.

It's not clear to me, and either way I believe the draft should be
clearer on these points (see also my latest response to Petr.  If the
intent of the draft is to prohibit any user customization, it should
explicitly say so (with, IMO, some more explanation); if the intent is
to allow such customization, I believe we should actually loosen it to
SHOULDs).

--
JINMEI, Tatuya

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[神明達哉]

At Fri, 26 Jan 2018 17:32:33 +0100,
Petr Špaček  wrote:

> > as these are requirements without a user-configurable knob.  If the
> > actual intent was just to specify the default behavior with a
> > configurable knob, I'd expect SHOULD-variants are used in cases like
> > these.
>
> Oh, I can see your point. Let me rephrase what I'm trying to say:
> I personally agree with the doc, it makes sense to me, and I do not
> believe that its wording prevent anyone from adding knobs they want.
> Software in the end will do whatever its developers wanted, which might
> include knob to override any part of spec.
>
> An example: RFC 4033 clearly states what should be done if result of
> validation is "Bogus". Nonetheless, Unbound has "val-permissive-mode:
> yes" which enables admin to pass bogus answers.

It's true that an implementer sometimes even ignore MUSTs.  And it's
also true that we (the IETF) can't do anything to prevent that; after
all there's no protocol police.

IMO, however, that doesn't mean we can casually use the fact to
silence objections when the requirement level might actually be too
strong.  In my understanding and also according to my experiences,
MUST requirements are in fact very strong.  Even "I do whatever I want
no matter what the standard says"-kind of customers often accept that
something cannot be implemented when it's prohibited with a "MUST
NOT".  It's much more likely that implementations (especially
open-source kinds, which tend to respect standard more literally) do
not provide a knob to change a MUST behavior.  And, if you write your
own implementation that doesn't follow a MUST, the reputation risk is
much higher than when you are just against a SHOULD.

So, if we want to use the strongest requirement level, especially when
it's somewhat controversial, I believe that the onus is on the authors
(and the WG that supports them) to explain why that level is necessary
more carefully and in detail.  On the other hand, if we really mean
silencing arguments against the requirements with the existence of a
user-configurable knob, then IMO what we should actually do is to
loosen the requirement level so that it explicitly allows such a knob.
(I'm actually not sure whether those who showed support moving forward
definitely wants to keep the MUSTs or they can live with SHOULDs).

--
JINMEI, Tatuya

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[神明達哉]

At Fri, 26 Jan 2018 12:47:29 +0100,
Petr Špaček  wrote:

> > I myself don't have a particular opinion on whether to send it to the
> > IESG, but I don't think it's ready for it based on my understanding of
> > the WG discussion so far.  In particular, I don't think I saw a wg
> > consensus about one major objection to the idea: "I'd like to keep my
> > right of configuring my DNS servers (authoritative or recursive) to
> > return whatever I want to 'localhost' queries".  Again, I personally
> > don't claim this right, but I see the concern.  If my observation is
>
> Software is still free to provide knobs to deviate its behavior from
> RFC, which is nothing unusual when it comes to DNS(SEC).
>
> Is there a real problem to solve? My understanding is that this document
> is stating what software should do by default.

Hmm, that's different from my interpretation of the draft.  According
to my usual interpretation of IETF docs, I would interpret these from
Section 3:

   3.  Name resolution APIs and libraries MUST recognize localhost names
   as special, and MUST always return an appropriate IP loopback
   address for IPv4 and IPv6 address queries and negative responses
   for all other query types.  Name resolution APIs MUST NOT send
   queries for localhost names to their configured recursive DNS
   server(s).

   As for application software, name resolution APIs and libraries
   MUST NOT use a searchlist to resolve a localhost name.

   4.  (Caching) recursive DNS servers MUST respond to queries for
   localhost names with NXDOMAIN.

   5.  Authoritative DNS servers MUST respond to queries for localhost
   names with NXDOMAIN.

as these are requirements without a user-configurable knob.  If the
actual intent was just to specify the default behavior with a
configurable knob, I'd expect SHOULD-variants are used in cases like
these.

--
JINMEI, Tatuya

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[神明達哉]

At Mon, 22 Jan 2018 11:18:08 -0500,
Suzanne Woolf  wrote:

> Please focus feedback on: Is this draft ready to go to the IESG for
> approval as an RFC? If not, can you suggest specific changes it
> needs?

I myself don't have a particular opinion on whether to send it to the
IESG, but I don't think it's ready for it based on my understanding of
the WG discussion so far.  In particular, I don't think I saw a wg
consensus about one major objection to the idea: "I'd like to keep my
right of configuring my DNS servers (authoritative or recursive) to
return whatever I want to 'localhost' queries".  Again, I personally
don't claim this right, but I see the concern.  If my observation is
correct and the WG has actually not reached a clear consensus on this,
I believe it should first achieve it.  If I miss a reached consensus,
I wouldn't oppose to it, but I believe the draft should discuss
how/why it justifies dismissing such concerns.

Some specific comments on the 02 version follow.

- (editorial) Section 1:
   This increases the likelihood
   that non-conformant stub resolvers will not go undetected.

  This is a kind of double negation ('not...undetected') and it was
  difficult to me to understand it on a first read.  I'd suggest
  revising it to, e.g:

   This increases the likelihood
   that non-conformant stub resolvers will go detected.

- Section 2

   The domain "localhost.", and any names falling within ".localhost.",
   are known as "localhost names".

  I'm afraid this definition can be a bit ambiguous.  It could read as
  if "a.localhost.example.' is a 'localhost name'.  I'd suggest:

   The domain "localhost.", and any names ending with "localhost.",
   are known as "localhost names".

- Section 3

   1.  Users are free to use localhost names as they would any other
   domain names.

  It's not clear to me what this sentence means.

- Section 3

   7.  DNS Registries/Registrars MUST NOT grant requests to register
   localhost names in the normal way to any person or entity.

  It's a bit awkward to me to use an RFC2119 keyword for what
  registries/registrars should (or should not) do.

- Section 5.1

   In this
   case, the requirement that the application resolve localhost names on
   its own may be safe to ignore, but only if all the requirements under
   point 2 of Section 3 are known to be followed by the resolver that is
   known to be present in the target environment.

  I don't understand this sentence, especially the phrase "if all the
   requirements under point 2 of Section 3 are known to be followed by
   the resolver".  Point 2 of Section 3 talks about application
   behavior (and I interpret "application" is a user of resolver, not
   resolver itself), so what does it mean by "known to be followed by
   the resolver"?

- Section 5.2

   Hosts like "localhost.example.com" and
   "subdomain.localhost.example.com" contain a "localhost" label, but
   are not themselves localhost names, as they do not fall within
   "localhost.".

  I suggest: 'as they do not end with "localhost.".' (see my comment on
  Section 2 above).

- Section 6.1

   Some application software differentiates between the hostname
   "localhost" and the IP address "127.0.0.1".

  You might also want to refer to ::1 here.

--
JINMEI, Tatuya

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[神明達哉]

At Thu, 25 Jan 2018 16:03:08 +,
Tony Finch  wrote:

> > I am not nearly so enthusiastic about an important component of
> > the draft.  Specifically, I'd like to suggest that while the
> > requirement for recursive resolvers to return NXDOMAIN for "localhost."
> > is well-intentioned, it will prove counter-productive to the
> > motivating goals of this draft.
>
> This is a legitimate worry, but it's based on incorrect information.
>
> Stub resolvers already sink localhost queries themselves - they don't rely
> on their recursive servers.

Could you be more specific about it?  It may be a minority
implementation, but I thought traditional stub resolver
implementations in BSD variants systems (getaddrinfo/gethostbyname
with the backend of libresolv) didn't hardocde special logic for
"localhost." yet.  It's true that such implementations refer to
/etc/hosts and it has system-installed mapping between 'localhost.'
and ::1 by default.  Do you mean (in addition to hardcoding the
special logic) this kind of combination of generic implementation with
default system configuration?  I'm asking this because I think the
difference between this and hardcoded implementation can matter in the
context of this draft.

--
JINMEI, Tatuya

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

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

[神明達哉]

At Thu, 11 Jan 2018 11:29:20 -0800,
Ólafur Guðmundsson  wrote:

> > > In the spirit of being helpful to recursive resolvers the right answer
> > IMHO
> > > is the referral from the
> > > zone above the query name.
> >
> > I'm not sure if I understand you so please let me be more explicit.
> > Are you talking about the so-called grandparent problem case, like the
> > case of this thread?
>
> yes

Okay, then, I don't think this is correct:

>> I hate having my own RFC thrown at me,
>> but it may or may not apply as there is another corner case that I/WG did 
>> not consider,

in that you should have considered it at the time of drafting RFC3658
(Section 2.2.1.2.).  And, at the risk stating something too obvious to
you, my understanding of the rationale of the RFC is that:

  when a server authoritative for root-servers.net. and for . , but
  not for net receives a query for root-servers.net/DS and if it
  returns a referral to net, a non-DNSSEC-aware resolver can consider
  it a lame delegation, since the resolver may think it already
  reaches the root-servers.net zone but see a referral higher than
  that.

This makes sense to me.  Now, given you should already well understand
it, perhaps you mean this case should be considered too minor and it's
better to make DNSSEC-aware resolvers happier at the cost of making
older resolvers suffer from false-lame?  If so, I see it's worth
discussing.  But IMO that would be far beyond the scope of an errata
(as this thread originally suggests) - it should be discussed in a
scope of some official bis specification.

--
JINMEI, Tatuya

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

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

[神明達哉]

At Wed, 10 Jan 2018 17:05:00 -0800,
Ólafur Guðmundsson  wrote:

> >That is, it answers as if it is authoritative and the DS record does
> >not exist.  DS-aware recursive nameservers will query the parent zone
> >at delegation points, so will not be affected by this.
> >
> I hate having my own RFC thrown at me,
> but it may or may not apply as there is another corner case that I/WG did
> not consider,
> what if the NameServer is authoritative for a zone above the parent.
> In this case it has to select does it answer from the closest zone that can
> answer DS record or
> from the zone it self.
>
> In the spirit of being helpful to recursive resolvers the right answer IMHO
> is the referral from the
> zone above the query name.

I'm not sure if I understand you so please let me be more explicit.
Are you talking about the so-called grandparent problem case, like the
case of this thread?

>> The root servers are authoritative for root-servers.net. and for . , but not 
>> for net

and, when this server gets a query for root-servers.net/DS, it should
return a referral to net instead of NODATA answer?  (If so, I'm
confused about what you said above "another corner case that I/WG did
not consider", since 2.2.1.2 of RFC3658 actually talks about that
corner case).

--
JINMEI, Tatuya

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

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

[神明達哉]

At Thu, 4 Jan 2018 08:12:26 +1100,
Mark Andrews  wrote:

> The reply also has to work for STD13 clients which already know
> about the child zone. The NODATA response is the correct one despite
> it requiring more work for a DNSSEC client.

Section 2.2.1.1 of RFC 3658 also explains that point:

   [...]  As these queries are only expected to originate
   from recursive nameservers which are not DS-aware, the authoritative
   nameserver MUST answer with:

  RCODE: NOERROR
  AA bit:set
  Answer Section:Empty
  Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]

   That is, it answers as if it is authoritative and the DS record does
   not exist.  DS-aware recursive nameservers will query the parent zone
   at delegation points, so will not be affected by this.

--
JINMEI, Tatuya

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

Re: [DNSOP] Measuring DNS TTL Violations in the wild

[神明達哉]

At Sat, 2 Dec 2017 20:09:25 +0530,
Mukund Sivaraman  wrote:

> > Strictly speaking yes, it is the same as when a Secondary does not update
> > the zone for a long time.
>
> An authoritiative server operator knows what the consequence of setting
> SOA RDATA fields is. It isn't the same as a cache extending TTL as it
> sees fit, in spite of the loose coherency among primary and secondaries.
>
> I don't agree a downstream cache has authoritiative say about extending
> TTLs (except exceptional circumstances where the authority is
> unreachable ~serve-stale).

+1.  I'd accept some level of liberty that an implementation can take,
such as ISC BIND 9 extending a 0-TTL of glue to 1 second:

/*
 * Glue with 0 TTL causes problems.  We force the TTL to
 * 1 second to prevent this.
 */
if (rdataset->ttl == 0)
rdataset->ttl = 1;

but it should be limited to a quite small range.  How much is
acceptable may be debatable, but I wouldn't consider "Stretching TTL
from 1 Hour [...] for 10% or 10 minutes" to be acceptable at the
discretion of an implementation.

--
JINMEI, Tatuya

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

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

[神明達哉]

At Thu, 16 Nov 2017 22:02:33 -0800,
Paul Vixie  wrote:

> > Realistically, I expect virtually everyone will implement 3, given how
> > this kind of feature is sold in the marketing context.  ,,,
>
> me too. that's why, in:
>
> https://mailarchive.ietf.org/arch/msg/dnsop/zRuuXkwmklMHFvl_Qqzn2N0SOGY/?qid=ff8e732c964b76fed3bbf333b89b111f

> ...i wrote:
>
> > therefore a "serve stale" team within IETF-DNSOP was convened, to try to
> > standardize the methods and signal patterns necessary to extend the
> > usability lifetime of records when their authority servers are not
> > reachable at the time of normal TTL-based expiry. most of us recognize
> > that TTL's will continue to be stretched no matter what changes are or
> > are not made to the specification, and so we expect the resulting RFC to
> > document current practice _without recommending it_ and to also document
> > a new practice _with recommendations_ as to its proper uses.

This (including the entire message) looks reasonable to me, as long as
we mean it, i.e., we actually seriously work on the "new practice" as
a followup wg task, rather than just using it as an excuse to publish
the current serve-stale draft.

But I'd note there might be some confusion here (perhaps only for me,
though).  I've been having the impression that we are talking about
"signalling" between the stub and caching (usually recursive) server,
perhaps because it's a followup of this message:
https://www.ietf.org/mail-archive/web/dnsop/current/msg21339.html

But your suggestion is signalling (mainly) between caching and
authoritative servers, right?

I thought recommending to allow fallback to stale

>>> 1) when the request explicitly signals it is ok;

between stub and caching wasn't realistic, as I didn't see a strong
incentive for the developers and users of stub (except for
protocol-savvy kinds).  That's why I was pessimistic in my previous
message.  I see more reality if it's about signalling between caching
and authoritative since, as you pointed out, there may also be
incentive for authoritative operators to adopt the "new practice".

--
JINMEI, Tatuya

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

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

[神明達哉]

At Wed, 15 Nov 2017 05:41:04 +,
P Vix  wrote:

> >1) when the request explicitly signals it is ok;
> >2) when the request groks EDNS but might or might not understand
> >   a staleness option; or
> >3) in all cases.
> >
> >My current understanding is that you and Paul are of position 1, while
> >I'm at 3.  At first glance 2 would appear to be pretty nearly the same
> >as 3 as far as its permissive toward unaware clients, but
> >significantly it does at least provide signal you could still access
> >via protocol debugging (dig, tcpdump, etc).
>
> I expect you to implement 3. I expect us to document 1.

Realistically, I expect virtually everyone will implement 3, given how
this kind of feature is sold in the marketing context.  Open-source
reference implementations may implement 1 if it actually becomes the
standard behavior, but I bet any serious large-scale user of those
implementations will make a custom change to disable that part.  I'd
be sad about that, but that's quite likely to be the reality.

I don't want the IETF to standardize a bad practice, and in that sense
I'd personally prefer option 1 (or something that shares its spirit).
But, as an engineering group, if there's basically no chance to deploy
it I don't see a point of bothering to standardize it.

So, if we choose to document option 1, I'd like to know the plan of
this group of its deployability.  Is it that we optimistically think
that nearly all stub resolvers eventually (in 5-10 years?) support the
signaling option and enable it by default, and then server
implementations will gradually start honoring the standard (and until
then we'll just grumble about the deployment of non-compliant
implementations)?

--
JINMEI, Tatuya

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

Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

[神明達哉]

At Thu, 07 Sep 2017 13:42:45 -0700,
Paul Vixie  wrote:

> > If we don't work on a proposal like this, I'd love to see a specific
> > counter proposal that doesn't violate the current protocol
> > specification (i.e., using a cached answer beyond its TTL) and still
> > avoids resolution failure when authoritative servers are forced to be
> > non-responsive due to huge scale DoS attacks.
>
> i think the actual problem statement is broader, and that by solving for this
> narrow version, we would lose the complexity/capability tradeoff -- we'd add
> more state and more signaling at a cost higher than what we would get for it.

I'm not sure specifically what you mean by these, but...

> it's a general reachability problem not specifically ddos problem. reasons for
> not being able to refresh data in a cache include ddos, but also backhoes,
> wire cutters, squirrels, circuit breakers, and bad design/provisioning.

...I agree here.  I'm well aware of the generic nature of the issue,
but I mentioned one specific instance of the problem in my previous
message just because that's the most obvious one.

> i think the right answer will look like a miniature version of IXFR/AXFR and
> NOTIFY, such that a cache can register its intent to become a partial stealth
> secondary server, and by participating, an authority server can both indicate
> its willingness to have this done, and possibly remember what was transmitted
> so as to facilitate subsequent cache invalidation or zone change notification
> messaging. one could even imagine a dns cookie exchange at the outset, to help
> authenticate later messages. sort of a super-lightweight session protocol.

I guess we are also on the same page in a sense here.  One possible
justification for a behavior like draft-tale-dnsop-serve-stale is that
it can be considered a recursive server variant of a secondary
authoritative server that keeps using primary's zone content even if
the auth server is unreachable for a certain period (until, of course,
the entire zone expires).  If this makes some sense, we may be able to
develop a cleaner solution than serve-stale by expanding the
observation.

I'm not necessarily a fan of the specific approach described in
draft-tale-dnsop-serve-stale, but I have to admit it's a practical
workaround (if not a "solution") for a real-world problem happening
today.  I'd be happier if the wg agrees on working on a better
solution, but in that case we should also be pragmatic.  That includes
the recognition that any protocol extension that requires changes to
both recursive and authoritative servers will take quite long to
deploy.  Since the problem is real and current, the solution should
have an intermediate state that might look a mere hack.

--
JINMEI, Tatuya

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

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[神明達哉]

At Tue, 15 Aug 2017 13:40:00 +0200 (CEST),
Mikael Abrahamsson  wrote:

> > If it's a commonly-used name, isn't this a one-time event, though?  The
> > happy eyeballs client asks for A and , gets A because it was in the
> > cache, but  also winds up in the cache, and then because it's a
> > commonly used name, neither record ever goes stale again.
>
> That was the assumtion by a lot of people who aren't DNS experts
> (including me). Mark Andrews brought up that this might be a more frequent
> issue that people think.
>
> Also there is the issue that as the TTL becomes 0 and the RR is now no
> longer in cache, next question will trigger a lookup and if the
> authoritative nameserver is 400ms RTT away, then during these 400ms a lot
> of clients might only use IPv4 with current RFC6555bis proposal.

If it's a commonly-used name, I suspect the more straightforward
"prefetching" should suffice in practice:
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer/
Several popular recursive servers already implement the feature.
Some of them even enable it by default.

My impression on the rfc6555bis thread is that Mark wanted to make it
"safer" (in that both  and A responses are provided before trying
to establish a TCP connection) even in some near-worst cases, not just
"working in most cases in practice".  In that sense I suspect tricks
at the resolver won't help much, whether it's existing prefetch,
opportunistic refresh or bundled /A queries, since there are worst
cases where those don't work.  Whether we need this level of
perfection for rfc6555bis is a different question, though.

--
JINMEI, Tatuya

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

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

[神明達哉]

At Sat, 29 Jul 2017 14:27:57 +0100,
Tony Finch  wrote:

> > - One possible idea of another extended error code: one that indicates
> >   a type-ANY query is responded with just one type of RRset when there
> >   can be more.
>
> Note that it is almost always the case that ANY answers from
> non-authoritative servers are a subset of the records :-)
>
> And it seems difficult for a cache to determine when to use this extended
> error code. If the cache was populated by an A query (say) it can't know
> if this is a subset of the owner's records or not; if it populated the
> cache from an ANY query then the records can expire at different times, so
> it would have to keep track of this to know if the extended error becomes
> relevant.

Good point, I was not thinking about the full path from auth via
recursive to stub when I made this comment.  As you said it's not
straightforward.  This could still be possible, e.g., if the
authoritative server deliberately returns a single RRset to an ANY
query with the extended (error) code and the recursive server caches it
with marking the sense of the extended code.  But it will introduce
additional special case to the recursive server implementation, and
the benefit may not be worth the complexity.

--
JINMEI, Tatuya

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from 神明達哉

[神明達哉]

Hi, sorry for the delayed response.

At Tue, 25 Jul 2017 16:53:12 -0400,
Joe Abley  wrote:

>   https://mailarchive.ietf.org/arch/msg/dnsop/zy86pvg139PaKFXo-BO6SPUfh3k
>
> > I've reviewed the 04 version.  I still do not think it's ready to move
> > forward as it still abuses HINFO.  I understand some other people
> > don't care about this point, and some others may even love the idea
> > (those who are using it right now).  But I've also seen yet some other
> > people have the same concern, so it shouldn't be only me.  I don't
> > think we have a clear consensus on this point yet.
>
> The draft at present doesn't require an implementer to abuse HINFO;
> it provides options to avoid doing so whilst still meeting the
> described objectives of the proposal. Since abusing HINFO is not
> mandatory, I presume you are objecting to the proposal sanctioning
> such shenanigans at all.

(If I understand the subtle nuance of this text:-) I think your
understanding is correct.
>
> If I have that right (please correct me if I'm wrong) I don't think
> I am the right person to make the call, being just a lowly document
> scribe. If this remains a concern for you, I suggest that we defer
> that question to our chairs and ask them to gauge consensus. My own

Agreed - I think we have to agree to disagree here and I think neither
of us can convince the other.  It should better be left to the wg
decision.

> personal views of pragmatism vs. elegance shouldn't enter into it;
> this is a working group document.

> > To be hopefully a bit more productive, I have a specific counter
> > proposal: remove the mandatory text about the use of HINFO, e.g.,
> >
> > - remove this bullet from section 4
> >2.  A DNS responder can return a synthesised HINFO resource record.
> >See Section 6 for discussion of the use of HINFO.
> > - remove ', in which case...' from Section 4.2
> >If there is no CNAME present at the owner name matching the QNAME,
> >the resource record returned in the response MAY instead be
> >synthesised, in which case a single HINFO resource record SHOULD be
> >returned.
> >
> > In fact, in terms of externally observable behavior, synthesizing
> > HINFO is just one form of "selecting one RRset of the QNAME"; the
> > HINFO is added and immediately removed at the time of answering the
> > ANY query, so in that sense we don't have to bother to mention it with
> > normative keywords.
>
> This text suggests that my interpretation above is wrong, and what
> you are objecting to is just the way that the HINFO approach is
> described. I think the specification is more clear if we spell out
> the whole synth-HINFO approach in its entirety and don't try to
> subsume it into the "return a subset of { RRSets that there } u {
> RRSets that we just synthesised }".

(As I said above) I believe you interpreted my objection correctly.
This suggestion was an attempt of compromise, assuming people already
(ab)using HINFO want to continue their practice.

[...]

> I am not sure I understand the benefit of not including it, given
> that it is observable behaviour for a large number of domains today
> (even if that is so due to the volume of domains hosted at a single
> operator). I think we do better service to operators and
> implementors by describing what is implemented. As you point out,
> Cloudflare's implementation may be less general-purpose than BIND9
> or NSD, and that might be a reason for the implementation choices to
> be different. Cloudflare is unlikely to be the last non-general
> implementation, however, so perhaps the mechanism most appropriate
> there will be relevant to others.

I agree that being silent for existing deployment may not be ideal.
If we (wg) can reach a consensus that the HINFO-based approach is an
abuse, however, we can think of other way to address it.  For example,
we could mention it and clarify that it should be considered an abuse,
should be discouraged, and newer implementations should use other
approaches.  My suggestion was just based on the anticipation that we
can probably not reach this kind of consensus (especially about the
discouragement).

> > I've also noticed a couple of other points I raised in my previous
> > review (
> > https://www.ietf.org/mail-archive/web/dnsop/current/msg18746.html
> > )
> > were not yet addressed.  These are (section numbers are for 03):
> >
> > - Section 3
> >
> >1.  A DNS responder can choose to select one or subset of RRSets at
> >the QNAME.
> >
> >   'one or subset of RRSets' sounds a bit awkward to me
>
> I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a subset" 
> seems wrong, actually; since some vestigial fragment of a set theory lecture 
> in the depths of my pre-history is telling me that the empty set is always a 
> valid subset.
>
> > - Section 4
> >
> >A DNS responder which receives an ANY query MAY decline to provide a
> >conventional response, or MAY instead send a 

Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use

[神明達哉]

At Tue, 18 Jul 2017 18:20:56 +0530,
Mukund Sivaraman  wrote:

> Dealing with water torture and some other attacks have had several
> band-aid approaches that don't always work well in practice. The most
> promising (and what feels correct) is
> draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned
> zones.

Do you mean it's the most promising measure for authoritative servers?
If so, and if nsec-aggressiveuse is more widely deployed in resolvers,
and if the authoritative operators feel the pain so keenly, I'd rather
imagine they are willing to pay the cost of deploying DNSSEC.

If you mean it's the most promising measure for recursive servers, I
simply don't buy the argument.  (I made that comment while the wg
discussed nsec-aggressiveuse and it toned down quite a lot in that
sense as a result of it, so I believe it's based on a wg rough
consensus).

So, either way, I don't see a strong case for the trick of using
nsec-aggressiveuse on an unsigned zone with DNS cookies.

--
JINMEI, Tatuya

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

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[神明達哉]

At Mon, 03 Jul 2017 11:23:01 +0200,
"Peter van Dijk"  wrote:

> > In that sense I see some disparity with the
> > ALIAS record of Amazon Route53, one of the earliest (and probably
> > largest) players of the idea:
> > - Supporting other types of records than  and A
> > - Allowing different target names for different types
>
> As I replied to John Levine, we do not feel this is prudent at this
> stage. Operational experience with ANAME, once standardised and
> deployed, would be a good basis for another draft that is more
> extensive, like having a type bitmap - this would support both these
> features.
>
> > I don't know how critical these are for existing R53 ALIAS users, but
> > depending on that ANAME may not be able to be successful in practice.
>
> Outside of R53, most implementations appear to be similar. That’s a
> pretty decent installed base that we can try to convert!

I'm no by means an advocate of R53-ALIAS, but I suspect its deployment
base as an ALIAS variant is too big to ignore.  If we just keep
ignoring them with the wish of eventual conversion, I'm afraid it's
quite possible that we'll end up having two (or more) incompatible
variants, each has a non-negligible size of deployment.  IMO we should
more explicitly try to avoid that situation.  In that sense I'd like
to suggest contacting someone at Amazon to see if they are interested
in developing an interoperable standard version of ALIAS.

With such efforts and hopefully some hope to have the possibility of
having more compatible deployments, I have no problem with deferring
extensions itself.

--
JINMEI, Tatuya

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

[DNSOP] comments on draft-muks-dnsop-dns-opportunistic-refresh-00

[神明達哉]

I've read draft-muks-dnsop-dns-opportunistic-refresh-00.  In short my
current impression is: "interesting but not yet very convincing idea".

High-level comments:

It's an interesting idea.  However, depending on its main motivation
I'm not sure how effective it is.  As it's listed in the dnsop agenda
https://datatracker.ietf.org/meeting/99/agenda/dnsop/ with
draft-tale-dnsop-serve-stale, it may mainly intend to be a mitigation
in case the authoritative server of a popular name becomes
unreachable.  But, for this proposal to be effective in that case, the
resolver would have to query other names in the same zone
periodically.  I'm not sure if we can generally assume that in cases
where it matters (for example, for the "twitter.com" zone the resolver
may only query for "twitter.com").

Also, the target zone needs to be generally stable, so for example
it's not very effective if the zone is quite frequently updated.  I
can imagine some popular zones are frequently updated, e.g., for load
balancing purposes.  For example, in my quick experiments the SOA
serial of the facebook.com zone changes quite rapidly.

On the other hand I wonder some other popular zones may not rely on
SOA serials to keep its authoritative servers up to date (i.e., they
may not use the standard zone transfer mechanism to distribute the
latest version of zones to secondaries).

I can also think of a corner case where this approach doesn't work
well: assume a zone that changes very frequently and its serial can
wrap quite quickly.  unlike secondary authoritative servers that are
supposed to be notified reasonably timely via NOTIFY, a resolver may
not be able to notice intermediate changes quickly enough and
incorrectly assumes the zone hasn't changed when the serial has
actually wrapped around.  It's easy to dismiss such a case as
unrealistic, but as a formal protocol I don't think we should ignore
these cases too casually.

Given these observations, I'd first like to understand specifically
for what purpose under which assumptions this proposal is deemed to be
useful.  At this moment it's not very convincing to me.

Some specific comments on the draft text follow:

- Section 4.3

   Upon receiving a positive response containing an SOA RR and a valid
   ZONESERIAL EDNS0 option, the resolver SHOULD associate the zone's
   serial number with the RRs in the answer.

  I believe the resolver should also associate the zone name.  Perhaps
  that's the intent, but it's not very clear from this description.
  So it would be better to say so more explicitly.

- Section 4.3: what if the response contains a ZONESERIAL option but
  there's no SOA in the additional (or authority) section?

- Section 4.5

   o  An authoritative server receiving a misconfigured ZONESERIAL
  option in a query SHOULD return a FORMERR response.

   o  A resolver receiving a misconfigured ZONESERIAL option in a
  response MUST NOT interpret the serial number in any SOA RR in
  that response as an indication of zone freshness.

  It's not clear what "misconfigured" means.  It would help if this
  could be more specific.

- Section 5

  I'd suggest revising the format diagram as follows:

  1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +---+---+
 ! OPTION-CODE   ! OPTION-LENGTH !
 +-+-+---+---+
 |   Reserved  |R|
 +-+-+

  with the following description:

  Reserved   A 7-bit unused field.  It MUST be initialized to
 zero by the sender and MUST be ignored by the
 receiver.

  R  1-bit request/acknowledge flag.  This bit MUST be
 clear in requests [...same as the original text]

  The main motivation for this suggestion is that "Bit 7 of this
  field" in the original text might sound a bit ambiguous.  Even if
  it can be considered reasonably clear per common sense, I think it'd
  still be helpful if we specify the position in the diagram.  Also,
  in the suggested text the reserved area is just called "reserved"
  instead of calling the entire 8 bits "flags".  Not a strong opinion,
  but I think it's better as we might want to use some of the reserved
  area for non-flag type of data.

--
JINMEI, Tatuya

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

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

[神明達哉]

At Tue, 27 Jun 2017 13:15:52 -0400,
Dave Lawrence  wrote:

> >   Also, it's not clear to me why the TTL is set to 1 second.  Since
> >   it's actually expired, a zero TTL seems to be a more sensible choice
> >   here (a similar feature of unbound uses a zero TTL).  If there's a
> >   specific reason to avoid 0, it would be better to explain it
> >   explicitly.
>
> Added to document:
>
> "1 second was chosen because historically 0 second TTLs have been
> problematic for some implementations.  It not only sidesteps those
> potential problems with no practical negative consequence, it would
> also rate limit further queries from any client that is honoring the
> TTL, such as a forwarding resolver."

Okay.

> > - Section 4
> >
> >> Canonical Name (CNAME) records mingled in the expired cache with
> >> other records at the same owner name can cause surprising results.
> [...]
> >   I suspect this is quite specific to internal implementation details
> >   of BIND, [...] it's probably better to clarify it's specific to a
> >   particular implementation architecture.
>
> I struggled with how to incorporate this feedback, because I felt like
> it was already pretty clear that I was discussing BIND specifically.
> In the end the only change I made specifically about this was to say
> "The version of BIND" instead of just "BIND", because I'm not even
> sure whether it would be an issue in the latest versions.  I also
> swapped the sequence of events around to match the real incident that
> happened (A was received first, then later CNAME, versus the original
> doc saying CNAME then A).

My memory on this topic is already quite vague, but I guess I had this
impression since this paragraph begins with a generic sentence without
mentioning a particular implementation.  I'm not necessarily opposed
to the current text, but if I were to suggest something, I might say:

   This was observed with an initial implementation in BIND when a
   hostname changed from having an IPv4 Address (A) record to a CNAME,
   and could happen for other implementations depending on how they
   manage cached data.

In this suggested text I've made two unrelated changes:

- s/, where a hostname changed/when a hostname changed/
  sine the original phrase was a bit confusing to me (it could read as
  if it talked about something about the BIND implementation, but it's
  actually talking about in which case the problem happens).
- fixing typo: s/record.to/record to/
  You'll at least need to fix this one even if the other part of the
  suggestion is rejected.

--
JINMEI, Tatuya

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

Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

[神明達哉]

At Fri, 12 May 2017 06:45:52 -0500,
John Kristoff  wrote:

> > I've read draft-kristoff-dnsop-dns-tcp-requirements-02.
>
> Thank you for taking the time to read, review, and comment on it!
>
> > I think RFC7766 already pretty clearly states TCP is a MUST.
>
> IETF RFC 7766 does very explicitly declare TCP is a MUST in the context
> of DNS implementation.  It is also very explicit about not declaring
> this to be so from an operational standpoint, although with a strong
> warning about the consequences.  The last paragraph is Section 1 in that
> document is the operative text.  It was that in addition to my own
> operational and teaching experience I felt made this draft necessary. I
> tried to make this case at the meeting in Chicago and elsewhere that
> this is an important distinction that matters.  I can try to make this
> case more compelling and convincing in the text.

I understand this draft tries to focus on an operational standpoint.
It states the intent pretty clearly.  It's just that I wasn't
convinced about the need to publish a separate RFC for that purpose
with all the overhead.  But, if a new version provides more compelling
arguments about the need it might change my mind.  And, in any case, I
wouldn't be surprised if others see stronger need for a separate
operational document - it can be quite subjective.  That's why I said
I wouldn't be (necessarily) opposed to
>
> >   I'm not sure if DDNS update bolsters the need for TCP.
> [...]
> >   And I don't see any new trend that changes this practice.
>
> I see Tony has chimed on this so I'll simply add that the goal of
> Section 2 was not necessarily intended to make or bolster the modern
> argument for carrying DNS over TCP.  In fact, the purpose was to help
> show how it is difficult to conclude one way or another whether carrying
> DNS over TCP is an operational requirement or not. I can make this
> objective more explicit at the beginning of that section.

Regarding this, see my followup response to Tony.

--
JINMEI, Tatuya

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

Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

[神明達哉]

At Fri, 12 May 2017 11:35:26 +0100,
Tony Finch  wrote:

> >   I'm not sure if DDNS update bolsters the need for TCP.  In
> >   my understanding DDNS update exchanges are largely done over UDP
> >   today (e.g., ISC's nsupdate utility uses UDP by default):
>
> Well, that depends on the transaction size :-) My servers fairly
> frequently handle updates containing hundreds or records.
>
> And `nsupdate` basically assumes that TCP is available - it doesn't give
> the caller a way to find out what the server's maximum update size is.
> (Similarly, my `nsupdate` wrapper `nsdiff` also assumes transactions can
> be up to 64KB in size.)
>
> So I think you'll be sad if you try to deploy an UPDATE server without TCP.

I didn't make that comment to say we can deploy DDNS without TCP.
Citing the draft text again:

   At least two new, widely anticipated developments were set to elevate
   the need for DNS over TCP transactions.  The first was dynamic
   updates defined in [RFC2136] and the second was .  The
   former suggested "requestors who require an accurate response code
   must use TCP", while the later 

This read to me that DDNS elevates the need for DNS over TCP as
RFC2136 suggests to use TCP for an accurate response code (because TCP
is reliable but UDP isn't) and requestors are actually following that
suggestion.

My comment was to point out that this is probably not the case in
today's common practice: I suspect many requestors don't too much
worry about this particular point and don't really use TCP at least
for that reason by overriding utilities' default.  Of course, in some
deployments the transaction size can be quite large and require TCP.
I don't know how common such a deployment is, but regardless of that,
I don't think the current draft text tries to say that.  If the actual
intent is that large DDNS transactions can require TCP, it should
simply say so (it doesn't have to cite the above suggestion of
RFC2136; it's even a confusing distraction in that sense).  And, to
that end, it's not even specific to DDNS.  Even a normal query
response can be too large to fit in a UDP message even with EDNS(0).

So, in summary, I basically try to say I don't see anything special
about DDNS here.

Anyway, this is a pretty minor technical detail.  I don't think it
affects the overall quality of the draft very much.

--
JINMEI, Tatuya

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

Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

[神明達哉]

At Thu, 11 May 2017 06:57:51 -0400,
tjw ietf  wrote:

> There was a lot of consensus during our last meeting in Chicago that this
> should move forward, so it's time that we do so.
>
> This starts a Call for Adoption for:
> draft-kristoff-dnsop-dns-tcp-requirements
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/
>
> 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.

I've read draft-kristoff-dnsop-dns-tcp-requirements-02.  I don't have
a strong opinion on whether dnsop should adopt it.  It's a
well-written, technically sound document, but I don't see something
substantially new in it.  I think RFC7766 already pretty clearly
states TCP is a MUST.  While some additional clarification provided by
this draft may also be useful, I'm personally not convinced that it's
sufficiently substantial that justifies the overhead and resource
consumption of the wg.  If this were a yes-or-no vote, I'd probably
vote for 'no'.

That said, I wouldn't be opposed to adopting it either, and if it's
adopted I'm willing to review subsequent versions.

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

Finally, a few comments on the current version:

- Section 2.2
   At least two new, widely anticipated developments were set to elevate
   the need for DNS over TCP transactions.  The first was dynamic
   updates defined in [RFC2136] and the second was the set of extensions
   collectively known as DNSSEC originally specified in [RFC2541].  The
   former suggested "requestors who require an accurate response code
   must use TCP", [...]

  I'm not sure if DDNS update bolsters the need for TCP.  In
  my understanding DDNS update exchanges are largely done over UDP
  today (e.g., ISC's nsupdate utility uses UDP by default):

   −v
   Use TCP even for small update requests. By default, nsupdate uses
   UDP to send update requests to the name server unless they are too
   large to fit in a UDP request in which case TCP will be used.

  And I don't see any new trend that changes this practice.

- Section 3

   o  Recursive servers (or forwarders) MUST service TCP queries so that
  they do not prevent large responses from a TCP-capable server from
  reaching its TCP-capable clients.

  The term "forwarder" can be ambiguous (see, e.g, RFC7766).  You
  might want to use a different term to be clearer.

--
JINMEI, Tatuya

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

Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname

[神明達哉]

At Thu, 11 May 2017 06:55:55 -0400,
tjw ietf  wrote:

> I'm caught up with my day job, and the discussion on this has died down,
> but it looks like the work is moving along smoothly, it's time to kick off
> a Call for Adoption on this document. (well, maybe late).
>
> This starts a Call for Adoption for: draft-hunt-dnsop-aname
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/
>
> 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.

I support the adoption.  I'm willing to review subsequent versions.
Actually I've already reviewed the current version and provided
comments:
https://www.ietf.org/mail-archive/web/dnsop/current/msg20130.html
but as far as I remember I've not seen any response to it from the
authors.  I hope that was not because the comments were so stupid and
simply and silently dismissed.

--
JINMEI, Tatuya

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

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[神明達哉]

At Tue, 18 Apr 2017 13:54:54 +0100,
Tony Finch  wrote:

> > I also wonder whether it's okay to allow ' or A' and ANAME to
> > coexist for the same owner name.  Shouldn't it be prohibited similar
> > to that CNAME and other types can't coexist?
>
> From the point of view of a provisioning-side implementation of ANAME, the
> A and  records are pre-populated answers from the target name.

As long as those records are generated from the target name that would
probably be okay.  But the current draft doesn't seem to enforce it,
and, (probably unintentionally/implicitly) allows the following setup:

.example.com. ANAME .example.net.
.example.com.  2001:db8:: ; not populated from ANAME target
.example.net.  2001:db8::

This looks more like a prohibited "CNAME + other  for the same
name" situation to me.

--
JINMEI, Tatuya

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

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[神明達哉]

At Fri, 7 Apr 2017 18:11:39 +,
Evan Hunt  wrote:

> Here's the new ANAME draft I mentioned last week.
>
> This is similar to existing non-standard approaches (ALIAS records,
> CNAME-flattening, etc) but also sends the ANAME record to the resolver so
> that, if the resolver understands the ANAME type, it can re-query for the
> answer just as it would with a CNAME.

I've read draft-hunt-dnsop-aname-00 and have some comments on it.  I'm
aware that similar comments on some points have been made in this
thread, but I'm providing my own version at the risk of repeating as I
think these are not necessarily a complete duplicate.

Overall I agree this is worth trying to achieve.  There is a clear
need for the ability of defining an alias at a zone apex, and it will
be nicer if we provide a standard-compliant and interoperable way for
that.  I also agree that a long-term goal (hope) should deploy it in
the resolver side even if it will take quite long (if not fail), so
that authoritative server implementations can be kept lightweight and
simple.

I have one high-level concern in terms of the merit of providing a
standard/interoperable version of 'alias'.  As already noted in the
draft there are currently several proprietary mechanisms of 'alias',
mainly to allow an alias at a zone apex.  In order for the standard
version to be successful, it will have to be compatible with these
existing ones as much as possible and as long as it doesn't break
other DNS standards.  In that sense I see some disparity with the
ALIAS record of Amazon Route53, one of the earliest (and probably
largest) players of the idea:
- Supporting other types of records than  and A
- Allowing different target names for different types
I don't know how critical these are for existing R53 ALIAS users, but
depending on that ANAME may not be able to be successful in practice.

I also wonder whether it's okay to allow ' or A' and ANAME to
coexist for the same owner name.  Shouldn't it be prohibited similar
to that CNAME and other types can't coexist?

Some specific comments on the draft text follow:

- Section 3

   If the original query is for type A, and an RRset of type A exists at
   the final ANAME , then that A RRset (with  changed to
   match that of the ANAME RR), MUST be appended to the answer section
   after the ANAME RRset.

  What if the target name of ANAME does not exist (NXDOMAIN)?
  Returning NXDOMAIN is quite likely to be a bad choice, since the
  owner name of the query actually does exist.  It will be certainly
  problematic if it's a zone apex.  So should it be translated into
  NOERROR+NODATA?  Or something else?  Also, if the zone is signed,
  what kind of proof should be returned?

- Section 3.1

   Address records cached locally MUST have a limited TTL.  The initial
   TTL for locally-cached address records MUST be set to the lesser of
   the ANAME TTL and the TTL of the address records retrieved from the
   ANAME .  The local TTL MUST count down, just as it would in a
   conventional resolver cache.[...]

  Should the local TTL count down, even if the initial value is from
  the ANAME TTL?  I suspect that's not the intent, and if I'm correct
  I think the current text is confusing and should clarify it.

- Section 3.2

   If the zone is configured with an A or  RRset at the same DNS
   node as ANAME, then the ANAME is considered to have been pre-expanded
   for zone transfer purposes.  When a zone is being transferred to a
   secondary server, if any address record already exists at the same
   node as an ANAME RR, then the ANAME RR MUST NOT be further expanded
   by the authoritative server.

  (I have a more fundamental concern about the coexistence as stated
  above, but ignoring it in this context) I'm afraid this text talks
  about something not explained before this point or not even
  explained clearly anywhere in the draft.  I guess the "pre-expand"
  means the following behavior described in section 3.3, but not
  necessarily with RRSIGs:

   Implementers MAY allow address records associated with the ANAME to
   be populated and signed by the primary server, then sent along with
   their RRSIGs to secondaries via zone transfer.

  If my understanding is correct, the concept of population/pre-expand
  behavior for zone transfer should be explicitly introduced before
  the discussion in Section 3.2.

--
JINMEI, Tatuya

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

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

[神明達哉]

On Thu, Mar 16, 2017 at 12:11 AM, tjw ietf  wrote:

> During the first WGLC of draft-ietf-dnsop-refuse-any, several issues were
> raised by the working group that needed to be addressed. The Authors
> addressed the issues, but the changes are enough that there should be a
> second Working Group Last Call on the changes.
[...]
> Please take a few moments to refer the changes and let the working group
> know if the document is ready to move forward.   We're mostly looking for
> remaining issues that have not been addressed.

I've reviewed the 04 version.  I still do not think it's ready to move
forward as it still abuses HINFO.  I understand some other people
don't care about this point, and some others may even love the idea
(those who are using it right now).  But I've also seen yet some other
people have the same concern, so it shouldn't be only me.  I don't
think we have a clear consensus on this point yet.

To be hopefully a bit more productive, I have a specific counter
proposal: remove the mandatory text about the use of HINFO, e.g.,

- remove this bullet from section 4
   2.  A DNS responder can return a synthesised HINFO resource record.
   See Section 6 for discussion of the use of HINFO.
- remove ', in which case...' from Section 4.2
   If there is no CNAME present at the owner name matching the QNAME,
   the resource record returned in the response MAY instead be
   synthesised, in which case a single HINFO resource record SHOULD be
   returned.

In fact, in terms of externally observable behavior, synthesizing
HINFO is just one form of "selecting one RRset of the QNAME"; the
HINFO is added and immediately removed at the time of answering the
ANY query, so in that sense we don't have to bother to mention it with
normative keywords.

Regarding the choice of HINFO in case of synthesizing, it may make
sense to specify a particular type as part of normative spec if many
other implementations are going to implement it.  But, as Section 8
explains two major general purpose open source implementations, NSD
and BIND 9, seem to only support the "subset" approach.  I suspect
it's actually not feasible for those generic implementations to
hardcode HINFO as long as their users could also use that type as
"real zone data".  Some special purpose implementation with full
control on what it configures, like in the case of Cloudflare, may
freely explore the approach of synthesizing HINFO at their discretion.
But I don't think it necessarily has to be a part of normative part of
this spec, at least at this moment.

I've also noticed a couple of other points I raised in my previous
review (https://www.ietf.org/mail-archive/web/dnsop/current/msg18746.html)
were not yet addressed.  These are (section numbers are for 03):

- Section 3

   1.  A DNS responder can choose to select one or subset of RRSets at
   the QNAME.

  'one or subset of RRSets' sounds a bit awkward to me

- Section 4

   A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, or MAY instead send a response with a single
   RRSet in the answer section.

  "a single RRSet" doesn't seem to be fully consistent of "one or
  subset of RRSets" stated in the preceding section (see the previous
  bullet).

--
JINMEI, Tatuya

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-01.txt

[神明達哉]

On Mon, Jan 9, 2017 at 4:43 AM, Ray Bellis  wrote:

> I've submitted a -01 revision to address most of the feedback received
> so far.

I have some minor comments on this version.

- Section 3.1

   IP Version: The IP protocol version number used by the client, as
   defined in the IANA IP Version Number Registry [IANA-IP].
   Implementations MUST support IPv4 (4) and IPv6 (6).

  I suspect "IANA-IP" is defined as a 4-bit field simply because the
  version field of the IPv4 (and therefore IPv6) header is 4 bits.
  But I don't think this specification necessarily has to inherit the
  restriction, and while it's probably quite unlikely to see the need
  for more than 15 values, I also don't see why we have to be more
  future proof (at least we know "IPv10" is coming, right? :-).
  Although there's an unused 4 more bits, I think it's even better to
  have a 16-bit field and use address family numbers:
  
https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

- Section 3.2

   Proxies MUST append this option to each request packet received
   before sending it to the intended DNS server.

  This MUST sounds too strong to me as a general requirement.  Unless
  the upstream server needs the information provided in this option,
  there should be no interoperability problem even without this
  option.

- Section 3.3

   When this option is received from a white-listed client the DNS
   server MUST (SHOULD?) use the address from the option contained
   therein in preference to the client's source IP address for any data
   processing logic that would otherwise depend on the latter.

  I think this paragraph needs some more clarification.  I can easily
  imagine the server has an ACL that limits acceptable clients to
  those proxies.  But in that case the server should actually "use"
  the client's source IP address.  It's not a critical problem of the
  specification, but I think it's better to clarify the intended
  context to avoid such confusion of readers.

--
JINMEI, Tatuya

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

Re: [DNSOP] draft-ietf-dnsop-terminology-bis and "recursive resolver"

[神明達哉]

At Thu, 19 Jan 2017 13:51:33 -0500,
Ted Lemon  wrote:

> I'm updating a document for another working group, and Ralph Droms
> in his last call comments on that document asked me to use
> "recursive resolver" instead of "caching name server", referencing
> draft-ietf-dnsop-terminology-bis.   That document doesn't actually
> define "recursive resolver," but instead "full service resolver,"
> which means almost, but not quite, the same thing.   The document
> does use the term "recursive resolver" fairly liberally despite
> there not being a definition for it.   Given that "recursive
> resolver" is in such common use, including in this document, I think
> the document should include a definition for "recursive resolver".

I agree.  My understanding is that the original terminology draft
restricted itself to terms already defined in existing RFCs an that's
probably why "recursive resolver" wasn't given a definition.  I
thought we are now more flexible in bis, so it makes sense to me to
give a "formal definition" to widely used terms like "recursive
resolver".

--
JINMEI, Tatuya

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

[DNSOP] comments on draft-vixie-dns-rpz-04

[神明達哉]

This is my technical comments on draft-vixie-dns-rpz-04 that I
promised to submit when I responded to the wg adoption call.  Some of
the points may be considered "out of scope" if the draft really
intends to just describe what's currently deployed, but I nevertheless
made these points for the reasons I said in my response to the
adoption call.

- Abstract

   This document describes a method for expressing DNS response policy
   inside a specially constructed DNS zone, and for recursive name
   servers to use such policy to return modified results to DNS clients.

  I don't think this document limits its scope to recursive servers as
  it talks about the "recursive-only" option in Section 6.  The same
  sense of comment applies to some other use of "recursive servers"
  throughout the document.

- Section 4.1.1

  The BIND 9 RPZ implementation rejects a prefix length of 0:

  if (prefix_num < 1U || prefix_num > 128U) {
badname(log_level, src_name,
"; invalid prefix length of ", prefix_str);
return (ISC_R_FAILURE);
}

  I don't know the rationale behind it, but since /0 is not a
  syntactically invalid prefix it's probably better to describe it
  explicitly, if the restriction is intentional and especially if this
  document seeks for wider interoperability among multiple
  implementations.  Furthermore, if the intent is to avoid
  accidentally apply a policy to too broad addresses, some other
  shorter prefixes (e.g., /1) may also need a similar consideration.

- Section 4.1.1

   As in [RFC5952], in order to avoid confusion with octal notation,
   leading zeroes MUST be suppressed.

  This reads awkward or confusing to me.  First, it could read as if
  RFC5942 suppresses leading zeros to avoid confusion with octal
  notation, but as far as I understand it that's not the reason (it's
  basically just to provide unique and consistent representations.)
  Second, unlike the case of IPv4 addresses, not all hex block can
  this confusion; if avoiding the confusion were the reason, there
  should be no reason for banning '0db8' instead of 'db8'.  So I
  suggest:

   As in [RFC5952], in order to make the representation unique,
   leading zeroes MUST be suppressed.

- Section 4.2

   To control the policy for both a name and its
   subdomains, two policy RRsets must be used, one for the domain itself
   and another for a wildcard subdomain.

  IMO this part of the spec is one of the reasons why abusing zone
  data to represent filtering policies is not good.  I guess (and I
  know that's actually the case in some real world deployments) in
  many cases we want to apply the same policy to both 'example.com'
  and '*.example.com'.  So this spec can easily lead to wasting memory
  for straightforward implementations.  Although an implementation could
  employ an internal compression scheme to save memory, it seems to me
  to make much more sense to design the spec so a straightforward
  implementation would just work without a waste in the first place.

  Following the standard DNS protocol can also result in
  counter-intuitive results.  For example, if you have the following
  policy records:

  example.com CNAME .
  *.example.com CNAME .
  a.b.example.com  2001:db8::1

  then no policy will apply to a query for b.example.com./ or
  c.a.b.example.com./ (or other query types than  for that
  matter).  That would be quite likely to be different from what the
  admin of this config intends to implement (the most likely intended
  policy would be to return NXDOMAIN for everything on and under
  example.com except for a.b.example.com./).  We might say an
  admin of RPZ should be very familiar with all the subtlety of the
  DNS protocol details like this one, but to me this seems to be
  another case for designing a better spec at this opportunity.

- Section 4.4

   Recall also that the target of a CNAME is not added to the
   response if the QTYPE is ANY

  Is this guaranteed by a protocol standard?  Or is this a requirement
  to RPZ implementations?  (If it's the latter while the former isn't
  explicitly guaranteed, then I think the current draft should be
  clearer about it).

- Section 5.2

   Matches on rules in an RPZ specified earlier in the ordered list of
   RPZs take precedence over matches on rules in an RPZ specified later.

  I may miss something, but the concept of "ordered list of RPZs"
  isn't explicitly described elsewhere (at least earlier) in the
  draft.  I think it should be explicitly documented as part of
  assumptions.

- Section 5.6

   When comparing two Response IP Address matches or two NSIP matches on
   rules within a single RPZ, choose the match whose rule trigger has
   the longest "internal prefix length".  [...]
   For an IPv4 address trigger, the
   internal prefix length is the numeric value of its first label plus
   96 (that is, 128-32).

  Does this apply when a response to type ANY query contains both 
  and A RRsets, 

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

[神明達哉]

On Tue, Dec 20, 2016 at 7:16 AM, tjw ietf  wrote:

> The draft is being present as "Informational", and the point here is to
> document current working behavior in the DNS (for the past several years).
> It is obvious that some feel this draft is a large mistake, but like
> edns-client-subnet, more operators are deploying this than one is aware of.
>
> This starts a Call for Adoption for draft-vixie-dns-rpz
>
> The draft is available here:
> https://datatracker.ietf.org/doc/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.

I'm still reading the 04 version of draft-vixie-dns-rpz and intending
to make comments on it later, but I'd like to respond to the call
first: I do not think it's suitable for dnsop to adopt the draft in
its current form, with the intent of "just describing currently
deployed practice", and (as I guess) with the intent of eventually
publishing as an (Informational) RFC.

But I think the document itself is very useful, so it would be nice if
it's made more publicly available in other form, e.g., some
white-paper kind or at a popular blog site.  If the adoption means
polishing the document for that goal (although I don't think it's the
intent for this call), I'd support it.

Also, if we're really willing to work on a "standard, interoperable
DNS firewall specification" without worrying about substantially
changing the current practice/implementation, and if the adoption
means the first step for that goal (and so the final publication could
be totally different and may not be compatible with the existing
standard), then I'd support it.  But, again, I suspect that's not the
intent of this call.

Some more specific rationale for this opinion below:

- As I believe most people, and perhaps including the draft authors or
  RPZ implementations, agree, it's an ugly hack to use the standard
  DNS zone to represent the firewall rules.  It might have been a
  convenient way to implement the idea initially (e.g, we can use the
  zone transfer behavior to distribute the rules), but I don't see an
  essential reason why these are represented as DNS RRs.  And, (again
  as I believe everyone knows) it's not just ugly but also has some
  inherent flaws, such as that not all domain names can be represented
  due to length limitation.  In fact, not all existing implementations
  of RPZ-like feature use this form as the primary way of rule
  configuration (unbound is one example I happen to know of, and from
  a quick look knot resolver also seems to adopt its own configuration
  syntax).  Perhaps operators of these implementations use some
  conversion tools form the "standard" RPZ policies to its internal
  form, but that's obviously inconvenient.  Standardizing the spec
  more officially eventually leads to unified configuration (at least
  in concept) to eliminate the need for such a tool, but it would
  require changes to other existing implementations anyway.  Then it
  would be far better to develop a better form of policy
  representation from the beginning.

- If this is to be published as an IETF standard (even if
  "informational") and especially as a product of the dnsop wg, I
  believe it should contain more DNSSEC-related considerations.  The
  current situation is either
  + validly DNSSEC-signed responses bypass RPZ policies (when
'break-dnssec' is set to no), or
  + 'break-dnssec' is enabled, and it would currently confuse
validating stub resolvers
  As long as this wg hopes to see more such stub resolvers deployed
  (I'm assuming so), any of its protocol work should IMO help such
  deployment rather than hinder it.

- I know the above points are about to be dismissed with "these are
  out of scope of this doc; it just describes what is currently
  deployed".  And that's exactly another big concern of mine,
  especially because I heard the adoption of this draft would be
  similar to that of edns-client-subnet.  At that time several wg
  participants including myself raised unclear or ambiguous points of
  the spec, some of which were based on attempts of implementing it.
  Sadly, though, many of them were effectively silenced with the
  excuse of "not in scope".  Another excuse at that time was that
  there would be another standard truck doc to fix these issues, but,
  as quite predictably, people seem to have lost interest/energy once
  the RFC was published and there doesn't seem to be any attempt of
  revising the spec.  I've already sensed the same thing could happen
  for draft-vixie-dns-rpz from the adoption discussions on this list,
  and I don't like to see it actually happen.  To be clear, "really
  just describing what is currently deployed" is fine for me.  But my
  lesson from edns-client-subnet it can't well coexist with the intent
  of having more interoperable implementations.  If the intent is
  purely former, then it's better to 

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

[神明達哉]

Sorry for the delayed response.  I've been unusually busy for these
several weeks...

At Sat, 3 Dec 2016 12:44:47 -0500,
Olafur Gudmundsson  wrote:

> > I've read the 03 version of the document.  I do *not* think this is
> > ready for publication since I still believe we should not abuse HINFO
> > for this purpose as I argued a year ago:
> > https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
> > (But other than that I think the document is quite well written).
>
> We have some implementation experience with this and the fact that we return a
> Record that is parsed and displayed in human readable format has proven 
> valuable in
> dealing with “interoperability” problems.
> A number of “abusers” of ANY queries have seen this read the draft and said
>- yep I should have a fallback
> or- asking for exactly what I need is better way
>
> So what other RFC1034/5 defined type are you willing to throw under the bus?

(If synthesizing an otherwise-non-existent type of RRset is non
debatable) personally, I'd rather propose introducing a new RR type
specifically for this purpose so it's guaranteed to not cause
conflict or confusion.  "human readability with currently available
tools (e.g., a currently distributed version of dig)" is a well-known
excuse in cases like this or TXT abusers, but at least for a standard
track IETF protocol I believe we should take a more long-term view;
once we define the new type it won't take too long until common tools
like dig, drill, etc will catch up.  Until then relatively skilled
users can google what 'TYPE259' means and finds it's returned as
defined in RFC83xx.


> > Some specific comments on the text:
> >
> > - Section 3
> >
> >   1.  A DNS responder can choose to select one or subset of RRSets at
> >   the QNAME.
> >
> >  'one or subset of RRSets' sounds a bit awkward to me, partly because
> >  'a subset of RRSets' should include 'one of RRSets' and can thus be
> >  redundant, and partly because 'subset of RRSets" might sound related
> >  to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
> >  So I'd suggest changing this one of the following:
> >  - "one or a few of RRSets (but not all of them)"
> >  - "one or a few of RRSets"
> >  - "a subset of RRSets"
> >  I personally prefer the first most although it may be too verbose.
> >
> I  think the best way to address this to be consistent with Section 4 is to 
> say
> “one RRset” and be done with it

Works for me.  (But some others might want to avoid to be too
restrictive).
>
> > - Section 4
> >
> >   If the DNS query includes DO=1 and the QNAME corresponds to a zone
> >   that is known by the responder to be signed, a valid RRSIG for the
> >   RRSets in the answer (or authority if answer is empty) section MUST
> >   be returned.
> >
> >  Does this also apply to a synthesized HINFO (if so, by dynamically
> >  signing it?)?
> >
> Yes

Okay.  My objection to using HINFO in the first place aside, as long
as this hack is documented I think the doc should explicitly note it.

--
JINMEI, Tatuya

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

Re: [DNSOP] Second Working Group Last Call - draft-ietf-dnsop-nsec-aggressiveuse

[神明達哉]

At Tue, 13 Dec 2016 14:13:27 -0500,
tjw ietf  wrote:

> We felt another formal Working Group Last call was needed, though hopefully
> shorter.
>
> This starts a Working Group Last Call for:
> "Aggressive use of NSEC/NSEC3"
>   draft-ietf-dnsop-nsec-aggressiveuse
>
> Current versions of the draft is available here:
>https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
[...]
> Please review the draft and offer relevant comments. Also, if someone feels
> the document is *not* ready for publication, please speak out with your
> reasons.
>
> This starts a *one* week Working Group Last Call process, and ends at
> midnight 20  December  2016 UTC.

A bit belated, but I've read the 07 version.  I'm not necessarily
opposed to advancing it, but I personally it's better to spend some
more time to bake it.

The main reason is because the latest change to describe the
aggressive use of deduced wildcards with an equal weight is quite
substantial while I suspect many of the reviewers now only gave a
quick sanity check to confirm whether specific technical details are
addressed.  On a relatively fresh read after some period, I found the
07 version somewhat awkward in some places due to the latest change
(specific comments follow).

Similarly, it's not clear to me whether it now includes the idea of
aggressive use of NSEC/NSEC3 for returning NOERROR/NODATA?  I see a
new sentence in Section 4:

   Proof that a type does
   not exist is accomplished by providing a (DNSSEC secured) record
   containing the queried for name, and a type bitmap which does not
   include the requested type.

but, overall, it still seems to only assume the NXDOMAIN type of
negatives (see, e.g, a comment on Section 6 below).  If the intent is
to also support NOERROR/NODATA, I think we need another round of
overall updates (mostly an editorial effort, but not trivial).

Another reason for the wish of having some more discussion is that I
think the described justification for changing the recommendation in
RFC4035 is still weak (although I don't disagree with the change
itself).  Section 4 states:

   We believe this recommendation can be relaxed because, in the absence
   of this technique, a lookup for the exact name could have come in
   during this interval, and so a negative answer could already be
   cached (see [RFC2308] for more background).

But this argument has always been the case including when RFC4035 was
written.  As RFC4035 still made this recommendation...

   In theory, a resolver could use wildcards or NSEC RRs to generate
   positive and negative responses (respectively) until the TTL or
   signatures on the records in question expire.  However, it seems
   prudent for resolvers to avoid blocking new authoritative data or
   synthesizing new data on their own.  Resolvers that follow this
   recommendation will have a more consistent view of the namespace.

...I'd logically expect some new argument that was not true or not
recognized at the time of RFC4035 if we wanted to revise the
recommendation.  Examples of such a new argument include:

- some statistics that shows "a lookup for the exact name comes in
  during this interval" more often than previously expected, so it
  turns out the old recommendation really doesn't help much.
- the benefits of the aggressive use of NSEC(3)/deduced wildcards are
  now considered so big that they outweigh the prudence recommended in
  RFC4035.

I'd like to see something like these with convincing facts or
rationale in Section 4.

Specific comments:

- Title: "Aggressive use of NSEC/NSEC3"

  I think this should now be e.g., "Aggressive use of DNSSEC-validated
  cache" because of the equal weight given to the aggressive use of
  deduced wildcards.  Even if the aggressive use of NSEC/NSEC3 can be
  used as part of steps to use a deduced wildcard aggressively (i.e.,
  to confirm the query name wouldn't exist without the wildcard), the
  aggressive use of deduced wildcard has its own "aggressiveness" with
  its own caveats.  For example, in addition to the case where the
  wildcard-matched name is added to the zone, we also take the risk of
  not returning a negative answer sooner when the wildcard is removed.
  So I think this document should now use both NSEC/NSEC3 (for
  negative) and wildcard (for positive) equally when it says
  "aggressive use of XXX".  The above example suggestion is one
  attempt to do this.  And, if this suggestion makes sense, it should
  apply throughout the document (this is one reason why it's better to
  spend some more time before shipping it).

- Section 4

   queried for name.  In the first example above, if the (DNSSEC
   validating) recursive server were to query for dog.example.com it

  In this context I don't see why this has to be a recursive server.
  I also found some other occurrences of "recursive" when it doesn't
  necessarily have to be a recursive in that context.  It would be
  nice to clean up the 

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

[神明達哉]

At Fri, 25 Nov 2016 19:50:48 -0500,
tjw ietf  wrote:

> Please review the draft and offer relevant comments. Also, if someone feels
> the document is *not* ready for publication, please speak out with your
> reasons.
>
> *Also*, if you have any opinion on changing the document named from
> 'refuse-any' to 'minimal-any', please speak out.

I've read the 03 version of the document.  I do *not* think this is
ready for publication since I still believe we should not abuse HINFO
for this purpose as I argued a year ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
(But other than that I think the document is quite well written).

As for renaming the file, I don't have a strong opinion, but we expect
a bigger issue like HINFO can lead to more revisions, it would be good
to rename it at this opportunity in order to avoid confusion for
future readers.

Some specific comments on the text:

- Section 3

   1.  A DNS responder can choose to select one or subset of RRSets at
   the QNAME.

  'one or subset of RRSets' sounds a bit awkward to me, partly because
  'a subset of RRSets' should include 'one of RRSets' and can thus be
  redundant, and partly because 'subset of RRSets" might sound related
  to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
  So I'd suggest changing this one of the following:
  - "one or a few of RRSets (but not all of them)"
  - "one or a few of RRSets"
  - "a subset of RRSets"
  I personally prefer the first most although it may be too verbose.

- Section 4

   A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, or MAY instead send a response with a single
   RRSet in the answer section.

  "a single RRSet" doesn't seem to be fully consistent of "one or
  subset of RRSets" stated in the preceding section (see the previous
  bullet).

- Section 4

   If the DNS query includes DO=1 and the QNAME corresponds to a zone
   that is known by the responder to be signed, a valid RRSIG for the
   RRSets in the answer (or authority if answer is empty) section MUST
   be returned.

  Does this also apply to a synthesized HINFO (if so, by dynamically
  signing it?)?

- Section 6

   In the case where a zone that contains HINFO RRSets is served from an
   authority server that does not provide conventional ANY responses.

  This may be just because of my English literacy, but on my first
  read it was quite confusing to me; I first thought the second 'that'
  was a relative pronoun, which would make this text an incomplete
  sentence.  If there was a comma after 'server' that would be more
  readable for me.

- Section 7: a minor typo, s/implimentations/implementations/

   not return all RRSIGS.  In the wild there are implimentations that

--
JINMEI, Tatuya

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt

[神明達哉]

At Thu, 17 Nov 2016 11:36:04 +0100,
Ralph Dolmans  wrote:

> Maybe I'm missing something, but it is not clear to me whether this
> document (-06) allows generation of NODATA answers using matching NSEC
> records that do not have the QTYPE set in the type bitmap.
>
> I don't see it explicitly mentioned. The RFC4035 update in section 7
> seems to allow it (or at least not disallow it). However, Section 4 only
> mentions covering (not matching) NSEC records. Same in section 5.1: "The
> validating resolver needs to check the existence [...] and an NSEC RR
> covering the query name.".

FWIW, I raised the same comment/question for an earlier version:
https://www.ietf.org/mail-archive/web/dnsop/current/msg17875.html

I've checked the thread, and found that while Warren replied to my
comments this particular comment didn't have any followup:
https://www.ietf.org/mail-archive/web/dnsop/current/msg17993.html

I suspect it has been simply forgotten since then rather than
rejected.

--
JINMEI, Tatuya

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

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

[神明達哉]

At Tue, 15 Nov 2016 04:21:05 +0100 (CET),
Ondřej Surý  wrote:

> > I'm not sure how you can be so sure about the author's assumption when
> > the draft itself doesn't explicitly clarify the assumption (maybe
> > based on an off-list conversation with Fujiwara-san?), but if that's
> > actually the assumption, the current draft text is IMO so confusing
> > and misleading.  In that sense I'm with Bob and Stephan, and the draft
> > should be much clearer on the assumption.
> >
> > And IMO, with the assumption *corrected*, the draft's recommendation
> > becomes even less convincing to me.
>
> True, those are my assumptions about the draft based on the real world
> experiences about the general mess that DNS usually is and experiences
> with implementing a DNSSEC-validating resolver that has to cope with
> such mess.
>
> Therefore my view is that the resolvers cannot make any assumptions that
> anything in the DNS is *correct*, but only that it's as good as it gets
> and try hard to fulfill the original query.
>
> I generally think that we should improve the DNS if the overall outcome
> will be a better protocol (in any of stability, determinism, reliability,
> resilience, add your own...) even if it attacks or changes the existing
> paradigms without breaking existing deployments (to a limit).

Okay, in that sense I believe we are basically on the same page, even
if we may disagree on some specifics.  I also have real world
experiences where dogmatic application of what's written in RFCs
doesn't really work well and I agree this is one such case.  I also
think draft-fujiwara-dnsop-resolver-update-00 is a good start.  It's
just that the initial version of it is so misleading (and perhaps
partly as a result of that) the recommendations aren't very
persuading.

--
JINMEI, Tatuya

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

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

[神明達哉]

At Tue, 15 Nov 2016 03:12:43 +0100 (CET),
Ondřej Surý  wrote:

> > Yes, it is. Otherwise, what would be the point of using the NS in the
> > parent instead of the authoritative one?
>
> Let me rephrase it, the assumption here is that parent NS are:
> "as good as they get to resolve the names underneath", and that
> doesn't mean they are necessarily more or less "correct" than
> child NS.

I'm not sure how you can be so sure about the author's assumption when
the draft itself doesn't explicitly clarify the assumption (maybe
based on an off-list conversation with Fujiwara-san?), but if that's
actually the assumption, the current draft text is IMO so confusing
and misleading.  In that sense I'm with Bob and Stephan, and the draft
should be much clearer on the assumption.

And IMO, with the assumption *corrected*, the draft's recommendation
becomes even less convincing to me.

--
JINMEI, Tatuya

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

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

[神明達哉]

At Wed, 02 Nov 2016 15:10:18 +0900 (JST),
fujiw...@jprs.co.jp wrote:

> I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to
> improve resolver algorithm.
>
> Please read it and comment.

As promised, here are specific comments on the draft text:

- general: the title and file name seem to be too generic for the
  actual content.  I suggest making them more specific, focusing on
  the subject of this draft.

- Section 1

   [...] And it may break requirements of resolvers'
   answers described in Section 3.2.

  I don't get it.  Specifically which requirement does this refer to?
  And, specifically how this override break that requirement?

- Section 3.1

   As described above, parent side NS RRSet makes a new zone.  Parent
   side NS RRSet (referral) and glue records are all the information to
   access servers for the child zone.

   That is, resolvers SHOULD NOT use child side NS RRSet to iterate
   zones.

  There seems to be a logical leap between the first and second
  paragraph; I don't get why we SHOULD NOT use the child side NS
  RRset for subsequent iteration simply because the parent NS RRset is
  used for the iteration first time (which I guess the first para
  tries to say).  In fact, the child side NS RRset might be a more
  complete, accurate and up to date set of the NS, while some part of
  the parent NS RRset may be unusable.  This is related to the high
  level comment I made in my previous message - I see and support the
  seeming background motivation of this requirement, but I believe we
  need more careful considerations and probably a much less drastic
  update.

- Section 4

   However, people sets different NS RRSets with mistakes, or
   intentionally.

  Specifically what kind of intent does this "intentionally" mean?
  btw, there's a typo here: s/sets/set/

- Section 4

   If the zone data of name server(s) specified by referrals and
   specified by zone apex NS RRSet are different, name resolution
   becomes unstable.

  I'd suggest changing it "name resolution *may* become unstable",
  since simply because they are different does not necessarily lead to
  an unstable behavior.

- Section 4

   The cache overwrite of NS RRSet may break
   "Referrals and glue records are information to access servers for
   child zones" specified by [RFC1034] section 4.2.1.

  I can't find the quoted text in any of RFC1034, let alone in Section
  4.2.1.  And, in any case, I don't understand what "may break" means
  here.  Please explain in more detail.

- Section 4

   The overwrite by zone apex NS RRSet induced security vulnerabilities.
   In 2012, "Ghost Domain Names: Revoked Yet Still Resolvable"
   [DUAN2012GHOST] was reported.  [...]

  While I see this incident is relevant to the subject of this draft,
  I think it can be misleading especially if it's intended to be used
  to support the current strong recommendation (to which I disagree)
  of this draft.  It may be true that the mastermind behind ghost
  domain names exploited a larger child-NS TTL with NS RRset
  replacement behavior of resolvers, I'd say this situation is quite
  extreme in that the admin of the zone is considered evil for a
  reason irrelevant to DNS itself and the parent zone tried to kill
  the delegation without the consent of the child zone admin.  In
  fact, this intent of the child zone admin could even be helpful if
  they are a good net citizen when there's an outage at the parent
  zone; as long as the child NS RRset is kept cached from the child
  zone, resolution attempts for the child zone will survive the outage
  of the parent.  So, this seems to me to be another case where this
  draft is one sided.  Referring to this incident is probably a good
  idea, but IMO it should actually be just one background story
  instead of a "vulnerability" evidence to support the killing of
  RFC2181 data ranking.

- Section 5.1

   [...] Resolvers MUST NOT use zone apex NS RRSets to iterate.

  As argued so far, IMO this recommendation is way too strong and
  should be changed.  (If we agree, we can discuss specially how we
  change it).

- Section 5.2

   Referrals and glue records in
   pre-loaded zone files MUST NOT be answered to stub resolvers.

  I don't understand what this sentence tries to specify.  Could this
  be explained in more detail?  I also don't understand why it
  specifically says "stub" resolvers; isn't it generally impossible
  for a responding DNS server (whether recursive or authoritative) to
  differentiate stub resolvers and non-stub resolvers?

- Section 5.3

   The update does not effect to DNS Query Name Minimisation [RFC7816]
   because answers from authoritative servers don't change.  Delegation
   cache and authoritative data cache separation will need small
   implementation changes.

  I don't understand the relationship between the first and second
  sentences.  Is the second sentence related to qname minimization?

- Section 5.4

   This update makes impossible to control 

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

[神明達哉]

At Wed, 02 Nov 2016 15:10:18 +0900 (JST),
fujiw...@jprs.co.jp wrote:

> I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to
> improve resolver algorithm.
>
> Please read it and comment.

In short: I support the motivation of the draft with some big
reservations about specific observations and proposals.

I agree that naive application of RFC2181 data ranking can lead to
problems and it's worth considering revisiting it.  One real-world
example I know of is the case where child-zone NS RRset is completely
bogus and none of the NSes are reachable while at least some of the
parent NS RRset are valid.  If a full-service resolver strictly
follows the RFC2181 ranking and replaces the parent NS RRset with a
"more trustworthy" set, any subsequent resolution attempt for the zone
will fail as long as the replaced RRset exists in the cache.  Although
we could say it's an operational error rather than protocol or
resolver implementation, this type of errors can so easily happen, so
I think we should also be able to deal with this situation in terms of
the protocol specification.

That said, the observation and recommendations of the current version
of this draft are IMO way one-sided and go too far.  IMO, the sense of
RFC2181 data ranking largely makes sense in that the people/organization
who has the authority of the zone should know the configuration of the
zone best and it's generally more likely that the data in the child
zone are more up-to-date and accurate.  For example, it's quite
possible that a subset of parent NS RRset is bogus while that in the
child zone is complete and accurate.  In this case, the recommendation
of this draft can rather lead to more "unstable" behavior as some of the
resolution attempts may unnecessarily try the bogus NS(es), resulting
in problems like longer resolution time or even timeouts
(a sophisticated server selection algorithm of the resolver may
mitigate the issues, but we cannot always rely on the smartness).

So, although I generally support the motivation of the draft, I'd
suggest making the recommendation more neutral and less drastic.  For
example, for the specific example of unreachable child-zone NSes I
mentioned above, it might be enough if we allow a resolver to keep and
use the parent NS RRset if it finds all of the child NSes to be
unreachable or somehow lame.

I also think it's overkilling to require specific caching data
structures like "authoritative data cache" and "delegation cache".
IMO this kind of details should be left to specific implementations,
and a protocol specification should only describe externally-visible
behaviors.  As currently written it's not so obvious whether this is
normative text or not, but at least it could be interpreted that way
given that it's intended to be an update to RFC1034.  If this is
just intended to be a conceptual example, it's probably fine, but in
that case the draft should clearly say so.

I plan to send specific comments on the draft text later.

--
JINMEI, Tatuya

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

Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-01.txt

[神明達哉]

At Wed, 26 Oct 2016 14:55:49 +0800,
"Jiankang Yao"  wrote:

> >If it's also intended to be used between recursive and
> >   authoritative, how does it handle a delegation answer?
>
> Most RRs needed to parallel query are normally located in the same zone.

That's probably true, but since this proposal is quite generic we
can't simply assume that in the description of the protocol.

> In case of that some sub-domain names are delegated, the Delegation 
> information will be returned to the recursive server.
> the recursive server then check the sub-domain based on the Delegation 
> information and get the answer.

I don't disagree with that as a high level observation.  But my point
in the question was that if it's supposed to work for delegation, it
should describe how it should work more clearly (specifically what
will be answered in the response from the authoritative server, and
specifically how the recursive server should react to it, etc).

> > - Should we assume SOA('s) in the authority section for negative
> >   answers?
>
> yes.

IMO things like this should also be explicitly included in the doc.

--
JINMEI, Tatuya

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

Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-01.txt

[神明達哉]

At Mon, 24 Oct 2016 21:58:42 +0800 (GMT+08:00),
"Jiankang Yao"  wrote:

>   We have updated it to the new version, simplying the mechanism.
>   pls kindly help to review it. any comments are welcome.
>   If Seoul DNSOP meeting has some time slot for it, I will appreciate it.

A few comments on a quick read:

- Does it assume to be used for exchanges between stub and recursive
  resolvers?  If it's also intended to be used between recursive and
  authoritative, how does it handle a delegation answer?

- Should we assume SOA('s) in the authority section for negative
  answers?

- What if AQ-TYPE is ANY?  I suspect the answer can be ambiguous in
  that case (even though it may not be a big issue in practice).  For
  example, if the first AQ-TYPE is ANY and the second is , and the
  answer section only contains one  (in addition to the answer to
  the main question), it's ambiguous for which AQ the  answer is.

- Likewise, what if the result is a CNAME chain?  For example, if the
  answer to the first AQ is a CNAME and the name for the second AQ is
  the CNAME's target, it can be ambiguous for which AQ the subsequent
  answer (that follows the CNAME answer) is.

- I wonder whether there are other cases where the results can be
  ambiguous and whether some of them can be more troublesome than the
  above examples.

- Maybe I missed something obvious, but the purpose of the AQ bit, and
  Count and Seq fields is not clear to me.  Some more explanations
  might help.

- Regarding the definition of "Prefix" in Section 3:

   o  Prefix field is a substring between the main domain name of the
  main quesiton and the accompanying domain name of the accompanying
  question.

  what "substring" means is vague to me.  It's not even clear whether
  this is an ascii string or it's a complete wire-format domain name.
  Likewise, the notation of "S-S1" is quite informal.  Since this is
  part of a formal definition, I'd suggest making it more formal and
  precise, eliminating any ambiguity depending on the interpretation.

- This part of Section 4 seems to assume a responder implementation
  generally echos back unrecognized EDNS options:

   [...] An AQ
   unaware responder is expected to ignore the AQ OPT of the query, and
   may echo the received OPT back into additional section of the
   response message.

  and the following part of Section 5 seems to rely on that
  assumption:

   If the initial value of the AQ-RCODE is unchanged in the response, it
   indicates that the responder is AQ unaware.

  But, as far as I know actual implementations tend to NOT echo back
  unrecognized options.

- Section 6: there's a missing period after 'example.com':

Answer |example.com  IN A 192.168.0.1  |

--
JINMEI, Tatuya

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-edns-key-tag

[神明達哉]

At Thu, 6 Oct 2016 03:00:36 -0400,
Tim Wicinski  wrote:

> The authors for this document have addressed some lingering  outstanding
> issues, and it appears ready for Working Group Last Call.
>
> This starts a Working Group Last Call for:
> draft-ietf-dnsop-edns-key-tag
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/
>
> Please review the draft and offer relevant comments. Also, if someone
> feels the document is *not* ready for publication, please speak out with
> your reasons.

I've read the 03 version of the draft.  I think it's basically ready
for publication.  However, I have two new points to discuss, which may
result in some non-trivial updates (although they may not be
substantial to warrant another WGLC).

1. regarding recursive resolvers (4.2.2.1), I wonder whether we
   want to explicitly note that the recursive servers MUST NOT (I
   think) forward a DNSKEY query with an EDNS key tag option when it
   already has it in the cache simply because the set of key tags in
   the originally query is different from its own set of key tags.

2. regarding the following note in Section 5.3:

   [ Note RFC1035 says NULL
   RRs are not allowed in master files, but I believe that to be
   incorrect ]

  perhaps we should officially update RFC1035 and clarify that NULL is
  now allowed in master files?  Even if the usage in the authoritative
  side (such as the example shown in Section 5.3.1) is not a normative
  part of this draft, the use of NULL RR is, and so it would be better
  to assure such configuration won't be considered a non-compliant
  setting.

--
JINMEI, Tatuya

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

Re: [DNSOP] Working Group Last Call

[神明達哉]

At Thu, 6 Oct 2016 02:49:34 -0400,
Tim Wicinski  wrote:

> >> I did some fix up - how do you like:
> >> "If a validating resolver gets a query for cat.example.com, it will
> >> query the example.com servers and will get back an NSEC (or NSEC3)
> >> record starting that there are no records between apple and elephant.
[...]
> >> Does that cover it sufficiently? (and I think I now better understand
> >> your concern).
> >
> > To be perfectly generic, "it will query the example.com servers" is
> > not always the case.  It (= validating resolver) might query another
> > intermediate resolver (often called a "forwarder") that performs
> > recursion.  By "external server" I tried to generalize the concept.
>
> Maybe this?
>
> "If a validating resolver receives a query for cat.example.com, it
> contacts its resolver (which may be itself) to query the example.com
> servers and will get back an NSEC (or NSEC3) record starting that there
> are no records between apple and elephant."

Yes, this is one way to address my point.  I'd leave it to the authors
specifically how to address it.

--
JINMEI, Tatuya

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

Re: [DNSOP] Working Group Last Call

[神明達哉]

At Tue, 4 Oct 2016 17:39:55 -0400,
Warren Kumari  wrote:

> > - Section 3: this section also has an issue of "recursive resolver".
> >   Although it may not be as critical as other part of the draft since
> >   it's only used as an example scenario, it's probably better to not
> >   limit the role of resolver to avoid misleading.  Maybe "recursive
> >   resolver" is just changed to "validating resolver", and
> >   "authoritative server" is changed to, e.g., "external servers"
> >   (meaning either authoritative or or other recursive servers).
>
> DONE.
> I did some fix up - how do you like:
> "If a validating resolver gets a query for cat.example.com, it will
> query the example.com servers and will get back an NSEC (or NSEC3)
> record starting that there are no records between apple and elephant.
> The resolver then knows that cat.example.com does not exist; however,
> it does not use the fact that the proof covers a range (apple to
> elephant) to suppress queries for other labels that fall within this
> range. This means that if the validating resolver gets a query for
> ball.example.com (or dog.example.com) it will once again go off and
> query the example.com servers for these names."
>
> Does that cover it sufficiently? (and I think I now better understand
> your concern).

To be perfectly generic, "it will query the example.com servers" is
not always the case.  It (= validating resolver) might query another
intermediate resolver (often called a "forwarder") that performs
recursion.  By "external server" I tried to generalize the concept.

I'm not sure how we address the subtlety without being overly
verbose.  Perhaps we can note in the terminology section that this
draft generally describes (validating) resolvers as those performing
recursive resolution, but the proposal will also work for resolvers
that rely on other recursive (or "full service" if you love to use
this term) resolvers.  And then we can keep Section 3 as is (as of ver
02).

> > - Section 4
> >
> >We believe this
> >recommendation can be relaxed because lookups for the specific name
> >could have come in during the normal negative cache time and so
> >operators should have no expectation that an added name would work
> >immediately.  We think that the TTL of the NSEC record is the
> >authoritative statement of how quickly a name can start working
> >within a zone.
> >
> >   I'm not necessarily opposed to this claim per se, but IMO it should
> >   provide some more careful justification.  [...]
>
> DONE
> I copied and pasted some text from Cheese Shop and also cleaned up
> this section somewhat.
> I think that I have now managed to successfully explain the reasoning,
> please let me know if you disagree / have suggested text.

Hmm, the new text in 03 doesn't seem to be so different from that of
02 on this point.  But this was actually what we reached as a
consensus I won't rehash it at this point.

> > - Section 5.2
> >
> >Implementations SHOULD enable aggressive use of NSEC by default.
> >
> >   On a fresh re-read of the draft, I'm now not so sure if this is
> >   clear enough and the requirement is reasonable.  First, does this
> >   also implies an implementation SHOULD implement aggressive use of
> >   NSEC?  Secondly, and especially if the answer to the first point is
> >   'yes', I'm not sure if SHOULD is reasonable.  Since this is just an
> >   optimization, it may be just up to the discretion of the
> >   implementor.
>
> Only implementations which want to support Aggressive NSEC should
> implement Aggressive NSEC. It's up to an implementer to decide if they
> want to have this feature or not.
> I've tried to clarify this with: "Implementations which support
> aggressive use of NSEC SHOULD enable this by default. Implementations
> MAY provide a configuration switch to disable aggressive use of NSEC
> and allow it to be enabled or disabled per domain."

Works for me.

> > - Section 9
> >
> >Aggressive use of NSEC / NSEC3 resource records without DNSSEC
> >validation may cause security problems.  It is highly recommended to
> >apply DNSSEC validation.
> >
> >   This paragraph is awkward.  I pointed this out several times, so I
> >   won't repeat it here - please refer to my previous comments.  One
> >   possibly new perspective is that this tries to cover cases where
> >   NSEC or NSEC3 is somehow cached before/without DNSSEC validation and
> >   note that such records shouldn't be used for the purpose of
> >   nsec-aggressiveuse.  If so, it might make some sense, but in that
> >   case it should be totally rephrased to avoid confusion or
> >   misleading.
>
> DONE.
> How is:
> "Aggressive use of NSEC / NSEC3 resource records without DNSSEC
> validation may create serious security issues, and so this technique
> requires DNSSEC validation."? I don't love it, additional suggestions
> or text welcomed.

To me the main point isn't address with this text.  I might be 

Re: [DNSOP] AAAA for e.root-servers.net

[神明達哉]

At Mon, 29 Aug 2016 12:01:20 -0400,
Warren Kumari  wrote:

> > On 29/08/2016 13:46, william manning wrote:
> >> You should probably wait until it's formally added to the root hints
> >> file.
> >
> > It is in the root hints file.
>
> It's also not super urgent.

I didn't mean to say it's urgent or to trigger a panic.

I just happened to notice 'dig @ . ns +norec'
now includes  for
e.root-servers.net, and that IPv6 address seems to work as a valid
root server, and the IPv6 address is in
http://root-servers.org/archives/2016-08-26/e-root.yml

All of these seemed to suggest this new IPv6 address is fully
operational and public, yet I don't remember I heard anything about
the addition.  So I thought I should have simply missed something,
and asked it here.  According to this thread, it looks like this is
indeed a news for some others.  If that's the case, perhaps the root
ops might think of a better way of publicizing this type of change
(not only for renumbering an existing address).  Otherwise it might
actually cause some kind of unnecessary "panic" next time.

--
JINMEI, Tatuya

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-02.txt

[神明達哉]

At Mon, 22 Aug 2016 21:57:12 +,
"Wessels, Duane"  wrote:

> > - Section 5.3
> >
> >   Unless the zone operator has intentionally added
> >   "_ta-" records to the zone, the server MUST generate an NXDOMAIN
> >   response.
> >
> >  Perhaps a pedantic comment, but I suspect this is not 100% accurate
> >  in that it could legitimately result in other response than
> >  NXDOMAIN, [...]
>
> I can be convinced either to keep it or to leave it.  My rationale for
> that sentence is to state that a server should not have some built-in logic
> that determines the response to these types of queries.  The response code
> should be determined by whether or not they are in the zone file (or as you 
> say
> covered by wildcard).

Okay, I see the point.  In that case I'd state that point more
specifically rather than through one such case of NXDOMAIN, but I'd
leave it to you.

> > - Section 5.3.1
> >
> >   When the response code for a key tag query is NXDOMAIN, DNS resolvers
> >   that implement aggressive negative caching will send fewer key tag
> >   queries than resolvers that do not implement it.
> >
> >  In the context of the interaction with nsec-aggressiveuse, I think
> >  this should be more generalized than the response to a key tag query
> >  itself, e.g.:
> >
> >   When a query results in an NXDOMAIN response with NSEC or NSEC3
> >   that covers the name of a key tag query, DNS resolvers that
> >   implement aggressive negative caching will send fewer key tag
> >   queries than resolvers that do not implement it.
>
> IMO your version adds a little unnecessary complexity to the sentence, while
> making the same point.

I don't think these two are exactly the same, but I won't insist on
the generalized text.

--
JINMEI, Tatuya

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[神明達哉]

At Fri, 19 Aug 2016 16:31:18 -0700,
"Paul Hoffman"  wrote:

> > - Section 2
> >
> >Therefore, it is important that resolvers be able to cope with
> >change, even without relying upon configuration updates to be
> > applied
> >by their operator.
> >
> >   If we really want to make it work "even without relying upon
> >   configuration updates", we may need to consider some extreme cases
[...]
> This seems like a far-fetched example that would require a new fallback
> mechanism. There are many, many reasons why the root server operators
> would prevent *all* the addresses from changing during the TTL.

I'm okay with dismissing the issue.

> > - Section 3.3 (DNSSEC with Priming Queries)
> >
> >   I remember I commented on this section before and we had discussions
> >   about how to address it.  I don't remember the conclusion at that
> >   time, but is this a result of that discussion?  I'm asking this
> >   because the current text still seems to have some explanation gap to
> >   me.
>
> The conclusion was the current text. In essence, it says "turn on DO if
> you want; although it is useless now, it might be useful in the future".

Okay, then that's fine for me.

--
JINMEI, Tatuya

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-02.txt

[神明達哉]

At Wed, 10 Aug 2016 16:54:39 -0700,
"Paul Hoffman"  wrote:

> [[ A month later, we're still eager to hear responses to the draft. We
> got a few that we have incorporated for a new version, but want to be
> sure we're on the right track before we move ahead. ]]

> > We understand that "specify more than one" is often an unpopular
> > choice in the IETF, about as unpopular as "don't get consensus on
> > one". This is a WG document so we need consensus even to go with two
> > ways. We look forward to hearing from you about this choice and how we
> > can move forwards.

On this specific point I don't have a strong opinion.  Personally, I
can live with the two-solution approach if it's deemed to be nearly
impossible to reach consensus on a single solution.  While I'd
definitely prefer a single solution, the current draft seems to
provide a reasonable explanation on why we have two at least for now.

Some specific comments on the 02 version follows:

- Section 1.1 (or for general discussion): another obvious downside of
  the QNAME-based approach is that it can't be used for all possible
  zone names because of the size limitation (255 octets) while adding
  extra label.  In practice, this is less likely to be a real issue
  since trust anchors would only be configured a higher level zones.
  But I think it's worth mentioning explicitly.

- Section 4.3

   A responder MUST NOT include the edns-key-tag option in any DNS
   response.

  I wonder whether it might be useful for a responder to signal its
  capability of understanding the option, either by including this
  option in the response or in some other way.  Then the resolver may
  use that information to suppress further unnecessary generation and
  inclusion of the key-tag option.  Not a strong opinion, but raising
  it just in case it's worth considering.

- Section 5.3

   Unless the zone operator has intentionally added
   "_ta-" records to the zone, the server MUST generate an NXDOMAIN
   response.

  Perhaps a pedantic comment, but I suspect this is not 100% accurate
  in that it could legitimately result in other response than
  NXDOMAIN, e.g., if there's a wildcard that would match the
  "_ta_" name even if (a record of) that specific name itself
  isn't added to the zone.  On the other hand, ignoring this
  nitpicking this requirement seems to be too obvious; if a name
  really doesn't exist in the zone, the server MUST surely return an
  NXDOMAIN, but it's not specific to this protocol, right?  So, in the
  end, I'd primarily suggest just removing this sentence.  Then we
  don't have to worry about making it very accurate, while IMO not
  leaving any obscure points.

- Section 5.3.1

   Aggressive NSEC/NSEC3 negative caching [draft-fujiwara-dnsop-nsec-
   aggressiveuse] may also affect the quality of key tag signaling.

  (nit) nsec-aggressiveuse is now a dnsop wg document.

- Section 5.3.1

   When the response code for a key tag query is NXDOMAIN, DNS resolvers
   that implement aggressive negative caching will send fewer key tag
   queries than resolvers that do not implement it.

  In the context of the interaction with nsec-aggressiveuse, I think
  this should be more generalized than the response to a key tag query
  itself, e.g.:

   When a query results in an NXDOMAIN response with NSEC or NSEC3
   that covers the name of a key tag query, DNS resolvers that
   implement aggressive negative caching will send fewer key tag
   queries than resolvers that do not implement it.

--
JINMEI, Tatuya

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[神明達哉]

At Sat, 13 Aug 2016 14:01:52 +0300,
Andreas Gustafsson  wrote:

> There is nothing wrong with existing resolvers that use the same
> timeout and retransmission strategies for priming queries as for any
> other query, and it seems wrong to me that a specific retransmission
> timeout should be required for some queries but not others.

+1.  This is actually I thought in my own read of the draft.
Mentioning a specific timeout value seems a clear overkilling (with no
apparent reason) to me, and while I wouldn't be necessarily opposed to
mentioning the retry at all, it's still awkward to me.  So I'd be
happier if it's simply removed.

--
JINMEI, Tatuya

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

Re: [DNSOP] Call for Adoption: draft-bellis-dnsop-session-signal

[神明達哉]

On Fri, Jul 22, 2016 at 6:39 PM, Tim Wicinski  wrote:

> This starts a Call for Adoption for draft-bellis-dnsop-session-signal
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/
>
> 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.

I've read the 01 version of the draft.  I don't have a strong opinion
on whether it's suitable for adoption, mainly because its motivation
is vague to me.  If it becomes clearer in a subsequent version I'll
probably be more supportive for the adoption.

Specific comments on 01:

- Section 1: perhaps its first 2 paragraphs intend to describe the
  motivation, but these are quite vague to me.  Since it's vague I
  can't propose any specific suggestion, but hopefully these will be
  revised to be more specific about what are the problems today and
  specifically how this proposal tries to address them.

- Overall: I think it's better to describe what the recipient should
  do if a MUST is violated.  In some cases it might be very minor
  and doesn't affect interoperability in practice, but implementors
  will still wonder what they should do in those cases.  Such cases
  include (if this is not a comprehensive list):
  Section 3.1:
Each message MUST contain only a single TLV.
  Section 4.2.1:
[..]It MUST NOT be initiated by a server.
  Section 4.2.2:
[...]  It MUST NOT be initiated by a
client.

- Section 3.1

   The Z bits are currently unused, and SHOULD be set to zero (0) in
   requests and responses unless re-defined in a later specification.

  Not a strong opinion, but in my experiences with other protocols on
  cases like this, I guess this would normally be a MUST for the
  sender and the recipient MUST ignore an unexpected value.

- Section 4.2.2

   The Terminate Session TLV (2) MAY be sent by a server to request that
   the client terminate the session.

  Specifically what does "terminate" mean?  It probably depends on the
  underlying protocol (TCP or DNSoTLS, etc), but it would be nicer if
  this document explicitly defines this term in Section 2 (maybe with
  an example for a specific protocol like TCP).

- Section 4.2.3: s/for.  a client/for a client/

   it may leave the current session idle for.  a client.  The definition

--
JINMEI, Tatuya

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