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

From: [email-masked]
Date: Wed, 02 Nov 2016 15:10:18 +0900 (JST)

Hello,

I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to
improve resolver algorithm.

Please read it and comment.

I also made a presentation of the same topic
at previous DNS-OARC workshop.

  https://indico.dns-oarc.net/event/25/session/6/contribution/19/material/slides/2.pdf

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

> From: [email-masked]
> 
> A new version of I-D, draft-fujiwara-dnsop-resolver-update-00.txt
> has been successfully submitted by Kazunori Fujiwara and posted to the
> IETF repository.
> 
> Name:		draft-fujiwara-dnsop-resolver-update
> Revision:	00
> Title:		Updating Resolver Algorithm
> Document date:	2016-11-01
> Group:		Individual Submission
> Pages:		9
> URL:            https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-resolver-update-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-resolver-update/
> Htmlized:       https://tools.ietf.org/html/draft-fujiwara-dnsop-resolver-update-00
> 
> 
> Abstract:
>    Parent side NS RRSet and glue records are all information to access
>    servers for child zone.  However, they may be overwritten by child
>    zone data (zone apex NS RRSet and other A/AAAA RRSets).  The
>    overwrite makes name resolution unstable and induces vulnerabilities.
>    RFC 2181 section 5.4.1 specifies trustworthiness of DNS data.  And it
>    is deemed that that all cached data (authoritative data, non-
>    authoritative data, referrals and glue records) are merged into one.
>    Resolvers may answer non-authoritative data, referrals and glue
>    records that should not be returned.  This document proposes updating
>    resolver algorithm that separates the cache to "authoritative data
>    cache" and "delegation cache".  The former is used to answer stub
>    resolvers, and the latter is used to iterate zones.
> 
>                                                                                   
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 2 Nov 2016 15:52:34 -0700

> 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

---

From: "Jiankang Yao" <[email-masked]>
Date: Thu, 3 Nov 2016 09:41:33 +0800

NS mismatch between parent zone and child zone is an issue.

I think that this draft is a very good start.

Jiankang Yao

From: fujiwara
Date: 2016-11-02 14:10
To: dnsop
Subject: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
Hello,

Regards,

> until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Bob Harold <[email-masked]>
Date: Thu, 3 Nov 2016 12:58:01 -0400

> I plan to send specific comments on the draft text later.

I agree:
- The child NS records should be used, and only fall back to the parent NS
records if all the child NS servers fail to get an answer to the query.
- Avoid specifying implementation details.

-- 
Bob Harold

---

From: 神明達哉 <[email-masked]>
Date: Thu, 3 Nov 2016 11:07:49 -0700

> 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 of TTL value of NS RRSet by
   the child zone owner.  However, overwrite of the referral does not
   occur always and TTL control may increase queries to authoritative
   servers.

  s/makes impossible/makes it impossible/
  The second sentence didn't parse well to me...could you explain what
  it tries to say in a different way?

- Section 8: I'm not sure about the intent of making this section
  empty, but I suspect this document will eventually need a non-empty
  Security Considerations section.  If this is just a TODO item for
  now, it's better to clearly note that in the draft.

--
JINMEI, Tatuya

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 5 Nov 2016 18:58:42 +0100

On Wed, Nov 02, 2016 at 03:10:18PM +0900,
 [email-masked] <[email-masked]> wrote 

> improve resolver algorithm.

I see the point but I have two practical reservations:

1) Having two separate caches may be a big change for some
implementations.

2) It will make debugging more difficult. With your two-caches system,
"dig @myresolver NS foobar.example" will retrieve the data in
foobar.example, while the resolver will use, when iterating, the data
from .example, which is not showed and I don't see a standard way to
retrieve it from the "delegation cache".

Apart from that, one detail: section 6 on implementations is too
short. You should expand it at least with the name of the
implementations (you mention two in your OARC talk, so it is not a
secret), and may be with RFC 7942 boilerplate.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Nov 2016 12:37:49 +1100

Or we could just ask that zone adminstrators and in particular gTLD
registry operators actually do what is required of them for operational
stability.  I don't see "except section 4 or 4.2 or 4.2.2 or 4.2.2
paragraph 3".  I do see a exception to restrict the use of hypens
in labels.

http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.pdf

1. Standards Compliance

1.1. DNS. Registry Operator shall comply with relevant existing
     RFCs and those published in the future by the Internet Engineering
     Task Force (IETF), including all successor standards, modifications
     or additions thereto relating to the DNS and name server
     operations including without limitation RFCs 1034, 1035, 1123,
     1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966. DNS
     labels may only include hyphens in the third and fourth position
     if they represent valid IDNs (as specified above) in their
     ASCII encoding (e.g., “xn--ndk061n”).

RFC 1034, Section 4.2.2. Administrative considerations

"As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so."

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 9 Nov 2016 11:59:39 +0100 (CET)

Fujiwara-san,

I was strongly opposed to the idea after your DNS-OARC presentation
and I am glad you are continuing the effort :).

I had some private conversation with Ralf Weber from Nominum and
we have conducted few experiments (and I plan to do more).

My biggest concern is that your draft is missing the impact on the
authoritative side:

1) what should happen when there's wrong NS at the child?
2) what should happen when there's no NS at the child?
3) what should happen in 1) and 2) when they are at the same server (generally the child NS is served)?

The most practical thing would be to require that child and parent NS MUST match, but we would
be saying at the same time that it won't be used at all.

The second concern is about TTL. You dismiss it very quickly in 5.4, but implementation wise - it would be probably best to split "delegation" and RR caches as you generally the query for:

"example.com." IN NS

should return child records with child TTL, but the delegation at parent could have different values with different TTL. Also I can imagine this will be very confusing to end-users - when I query my resolver for "IN NS" I generally want to know when the changes in the delegations will be reflected.

One possible way might be to return child NS in ANSWER and parent NS in AUTHORITY section in such case - but this needs to be addressed in the draft.

This will also have an impact on registries - usually the TTL at the parent is picked by the registry, but when the TTL at the parent could have such strong impact on the resolver behavior, the registries would have to modify their systems to allow TTL specification per delegated domain. This applies especially in the cases when the registry picks some large (but still reasonable) number for TTL.

P.S.: I am not so strongly opposed to the idea since I think a more deterministic approach to the resolution is generally a good thing, but I think there are many thing that need to be addressed before we can consider this to be an official standard and change in the paradigm how the domains are resolved.

Cheers,
Ondrej

--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

----- Original Message -----
> From: [email-masked]
> To: "dnsop" <[email-masked]>
> Sent: Wednesday, 2 November, 2016 07:10:18

>> URL:
>> https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-resolver-update-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-resolver-update/
>> Htmlized:
>> https://tools.ietf.org/html/draft-fujiwara-dnsop-resolver-update-00
>> 
>> 
>> Abstract:

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 9 Nov 2016 14:18:30 +0100 (CET)

One more thought I have just realized in the discussion with my colleague and that might tilt the scales towards the Fujiwara-san's proposal.

The modern authoritative nameservers tries to minimize the amount of data given back, so they don't fill an AUTHORITATIVE section for every query. The consequences of that is that a one more roundtrip would be needed to check the child-side NS.

I still don't know how to explain: "You absolutely must fill this in, but it will be never used unless the parent and child resides at the same server."

Cheers,
Ondrej

----- Original Message -----
> From: "Ondřej Surý" <[email-masked]>
> To: "fujiwara" <[email-masked]>
> Cc: "dnsop" <[email-masked]>
> Sent: Wednesday, 9 November, 2016 11:59:39
> Subject: Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

> The second concern is about TTL. You dismiss it very quickly in 5.4, but
> implementation wise - it would be probably best to split "delegation" and RR
> caches as you generally the query for:
> 
> "example.com." IN NS
> 
> should return child records with child TTL, but the delegation at parent could
> have different values with different TTL. Also I can imagine this will be very
> confusing to end-users - when I query my resolver for "IN NS" I generally want
> to know when the changes in the delegations will be reflected.
> 
> One possible way might be to return child NS in ANSWER and parent NS in
> AUTHORITY section in such case - but this needs to be addressed in the draft.
> 
> This will also have an impact on registries - usually the TTL at the parent is
> picked by the registry, but when the TTL at the parent could have such strong
> impact on the resolver behavior, the registries would have to modify their
> systems to allow TTL specification per delegated domain. This applies
> especially in the cases when the registry picks some large (but still
> reasonable) number for TTL.
> 
> P.S.: I am not so strongly opposed to the idea since I think a more
> deterministic approach to the resolution is generally a good thing, but I think
> there are many thing that need to be addressed before we can consider this to
> be an official standard and change in the paradigm how the domains are
> resolved.
> 
> Cheers,
> Ondrej
> 
> --

---

From: [email-masked]
Date: Fri, 11 Nov 2016 01:49:31 +0900 (JST)

Jinmei-san, thanks very much for your detailed comments.

I also received IPR claim from Nominum.

  https://datatracker.ietf.org/ipr/2907/
  https://patents.google.com/patent/US7769826B2/

I {will,need to} remove detailed algorithm {,to avoid IPR}.

Then, I will change the main contents to focus on problem collection
and proposal of requirements.

> From: 神明達哉 <[email-masked]>

Agree.
(I will submit next version to remove detailed algorithm to avoid IPR problem.)

>   And, specifically how this override break that requirement?

Ok, I will add more text...

>   need more careful considerations and probably a much less drastic

I agree that we need more careful consideration.

>   Specifically what kind of intent does this "intentionally" mean?

I considered "intentionally means "malicious idea".

next version will relfect your excellent comment.

Regards,

---

From: [email-masked]
Date: Fri, 11 Nov 2016 02:08:54 +0900 (JST)

> From: Stephane Bortzmeyer <[email-masked]>

Yes.

Two cache approach have patent problem.
There may be another implementation method.

> retrieve it from the "delegation cache".

- The simplest mode for the client is recursive, since in this
  mode the name server acts in the role of a resolver and
  returns either an error or the answer, but never referrals.
  (RFC 1034 Section 4.3.1)

  "dig @myresolver NS foobar.example" returns authoritative data.

> secret), and may be with RFC 7942 boilerplate.

  I will add.

Regards,

---

From: [email-masked]
Date: Fri, 11 Nov 2016 02:27:14 +0900 (JST)

Ondrej.Sury-san,

> From: Ondřej Surý <[email-masked]>
> Fujiwara-san,
> 

Resolvers with "overwrite" will become unstable.
Resolvers with proposed algorithm don't use the child NS.
Queries to parent authoritative servers do not increase.

> 2) what should happen when there's no NS at the child?

Resolvers with "overwrite" becomes unstable
if stub resolvers send child NS queries.
Resolvers with proposed algorithm don't use the child NS.
Queries to parent authoritative servers do not increase.

> 3) what should happen in 1) and 2) when they are at the same server (generally the child NS is served)?

Referrals from the grandparent is used.
Queries to the parent zone and the child zone is sent to the shared
authoritative server and it answers authoritative data of the child zone.

Resolvers with "overwrite" will become unstable
if stub resolvers send child NS queries.
Resolvers with proposed algorithm don't use the child NS.
Queries to authoritative servers do not increase.

> should return child records with child TTL, but the delegation at parent could have different values with different TTL. Also I can imagine this will be very confusing to end-users - when I query m…

True.

> One possible way might be to return child NS in ANSWER and parent NS in AUTHORITY section in such case - but this needs to be addressed in the draft.

It's good idea. Thanks.

> This will also have an impact on registries - usually the TTL at the parent is picked by the registry, but when the TTL at the parent could have such strong impact on the resolver behavior, the reg…

However, the overwrite does not happen always.

---

From: Bob Harold <[email-masked]>
Date: Thu, 10 Nov 2016 13:23:07 -0500

On Thu, Nov 10, 2016 at 12:27 PM, <[email-masked]> wrote:

> implementation wise - it would be probably best to split "delegation" and
> RR caches as you generally the query for:
> >
> > "example.com." IN NS
> >
> > should return child records with child TTL, but the delegation at parent
> could have different values with different TTL. Also I can imagine this
> will be very confusing to end-users - when I query my resolver for "IN NS"
> I generally want to know when the changes in the delegations will be
> reflected.
>
> True.
>
> > This will also have an impact on registries - usually the TTL at the
> parent is picked by the registry, but when the TTL at the parent could have
> such strong impact on the resolver behavior, the registries would have to
> modify their systems to allow TTL specification per delegated domain. This
> applies especially in the cases when the registry picks some large (but
> still reasonable) number for TTL.
>
There seems to be an assumption in this draft that the parent NS records
are always correct, but I would argue that this is not the case.

If all of the NS records in the child point to servers that fail to answer
for that zone, the zone breaks.
But the same happens if all the NS records in the parent point to servers
that fail to answer for that zone.

DNS treats parent NS records similarly to the root hints - as long as one
of them points to a working child server, it can get a list of the current
(true) list of NS records (from the child zone).  The child zone is the
authority for the NS records, not the parent zone.

-- 
Bob Harold

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 10 Nov 2016 20:46:55 +0100 (CET)

Bob,

----- Original Message -----
> From: "Bob Harold" <[email-masked]>
> Cc: "Ondřej Surý" <[email-masked]>, "dnsop" <[email-masked]>
> Sent: Thursday, 10 November, 2016 19:23:07

> are always correct, but I would argue that this is not the case.

Nope, I don't think this is an assumption of this draft or an assumption
of DNS status quo in general.

> authority for the NS records, not the parent zone.

What you have just described is an end-user (human) perception of how the
humans think the DNS operates.  The recursive DNS doesn't really care about
parent vs child distinction if it has at least one working path.  In the
contrary, always sticking to child NS records and disregarding the changes
in the parent might lead to "ghost domains" vulnerability.

Cheers,

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 10 Nov 2016 20:52:59 +0100 (CET)

Fujiwara-san,

the count of word "unstable" in your reply is exactly the reason
why I was so strongly opposed to your original proposal at DNS-OARC
as I think the Internet Standards should make things more stable
than unstable.

I quickly drafted several paragraphs during my PRG-AMS flight
and sending them over my short layover, so I won't be able to
send any updates in next 10+ hours.

Take it or leave it, and I would be also happy to provide more
text or co-author the draft if the result would end up in more
stable DNS including backwards compatibility and not introduce
even more mess into DNS.

Here it comes, feel free to incorporate it at various places,
or just wait, I'll try to merge it into your draft on my way
to Seoul.

~~~~~~~~~~~
Recent authoritative DNS server implementations try to minimize the
size of the DNS answers given to the clients.  One such technique to
minimize the amount of data sent back to client is removing all
unnecessary records from the answer such as content of AUTHORITATIVE
and ADDITIONAL section unless it's needed by DNS client to validate
the answer.

The side effect of such answer minimization is that the recursive DNS
server might not see the child zone apex NS records unless some client
of such resolver explicitly ask for NS records.  Therefore the
recursive DNS server behavior related to the delegation path is not
deterministic.

~~~

While it might be tempting to remove NS records in the child zone apex
as those NS records might never be used, there are several problems we
have identified:

  a) when the child and parent zone are served from the same
     authoritative DNS server instance, the child apex NS records
     would override any delegation NS records at the parent zone, thus
     any invalid or missing child zone apex NS records might cause
     denial of service for such a zone, especially when QNAME
     minimization is used by the recursive DNS server;

  b) behavior of strict recursive DNS implementation that doesn't yet
     implement delegation NS selection specified in this draft might
     get erratic or broken causing denial of service for the end user;

(TODO: Test all the common DNS server implementation.)

The recursive DNS servers MUST use delegation NS records in the parent
zone to follow delegation chain.  The recursive DNS servers SHOULD NOT
update the delegation chain with child zone apex NS records, but the
authoritative DNS operators MUST act as if the recursive DNS servers
might use the child zone apex NS records.

Therefore the delegation NS records in the parent zone and the NS
records in the child zone apex MUST follow the old semantics and MUST
be kept in sync to allow uninterrupted service for recursive DNS
servers that do not implement the delegation NS selection specified in
this draft.

~~~

The implementation of this draft will also affect the time to live
(TTL) for the delegation records as the TTL of the parent zone
delegation NS records will always be used.  It will not be possible to
update the delegation NS records TTL by changing the TTL in the child
zone.  Therefore the zone operators(?) are advised to plan the changes
in the NS records as if the maximum of child and parent TTLs was in
effect.

The parent zone operators are advised to allow child zone operators to
modify TTL value for parent delegation NS records.  The parent zone
operators might limit the minimum and maximum TTL values to mitigate
adverse effects on the parent zone operations.

~~~

The recursive DNS server implementations SHOULD implement different
caches for parent zone delegation NS records and child zone apex NS
records.

The recursive DNS server MIGHT implement the delegation cache snooping
by answering the IN NS query with child zone apex NS records in the
ANSWER section and the parent zone delegation NS records in the
AUTHORITATIVE section.
~~~~~~~~~

Cheers,

----- Original Message -----
> From: "fujiwara" <[email-masked]>
> To: "Ondřej Surý" <[email-masked]>
> Sent: Thursday, 10 November, 2016 18:27:14

---

From: bert hubert <[email-masked]>
Date: Fri, 11 Nov 2016 14:13:36 +0100

>   https://patents.google.com/patent/US7769826B2/

As a matter of policy, software patents are almost dead. Should we still
care?

https://en.wikipedia.org/wiki/Software_patents_under_United_States_patent_law#Post-Alice_period

"Few software patents have survived this analysis since the Alice decision
largely because they are written in purely functional language to claim a
result rather than describe a structure for accomplishing a result."

"In short, such patents, although frequently dressed up in the argot of
invention, simply describe a problem, announce purely functional steps that
purport to solve the problem, and recite standard computer operations to
perform some of those steps. The principal flaw in these patents is that
they do not contain an “inventive concept” that solves practical problems
and ensures that the patent is directed to something “significantly more
than” the ineligible abstract idea itself."

This matches the 7769826 patent exactly. There is nothing more technical in
there than "perhaps use a hash and multiple data structures".

Also, should we work with companies attempting to hinder progress by
clinging to patents which are no longer enforceable?

	Bert

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 11 Nov 2016 15:52:02 +0200

>   https://patents.google.com/patent/US7769826B2/

Just to avoid any possible misunderstanding, the IPR statement
referenced above was submitted by me in my capacity as a DNSOP
participant, as a third-party notification under RFC 3979 section
6.1.3, because I thought the working group should be aware that the
patent exists.  I am not currently affiliated with Nominum and did not
submit the statement on their behalf nor at their request.
-- 
Andreas Gustafsson, [email-masked]

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 11 Nov 2016 16:33:54 +0200

> I see the point but I have two practical reservations:
[...] 
> retrieve it from the "delegation cache".

A resolver that receives an RD=0 query for a name that is not present
in the cache should respond with a referral.  In a two-cache resolver,
the natural place to look for the data to include in such a referral
is the delegation cache, since that is where referrals are cached.

If the resolver does that, you can use

  dig +norecurse @myresolver random-subdomain.foobar.example

where random-subdomain is any unguessable label, for example
one derived from a 128-bit random number.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked]
Date: Mon, 14 Nov 2016 16:19:37 +0900 (JST)

Thanks very much for submitting IPR infomation.

The idea is not new and I heard that Nominum and some software implemented.

> From: Andreas Gustafsson <[email-masked]>

---

From: bert hubert <[email-masked]>
Date: Mon, 14 Nov 2016 21:06:11 +0100

On Tue, Nov 15, 2016 at 04:58:43AM +0900, Ted Lemon wrote:
> On Fri, Nov 11, 2016 at 10:13 PM, bert hubert <[email-masked]> wrote:
> Bert Huber wrote:
> Hm.   First, I tend to agree with you that the IETF should not work
> with companies that attempt to hinder progress by asserting patents.
> I am disappointed, however, that you would suggest that Nominum is
> such a company.  We've been active in the IETF since the company was

Ted,

I should have emailed it to this list as well. I did inform Andreas that I
misunderstood the origin of the IPR notification, which I assumed to be
Nominum.  I also tweeted about it. 
https://twitter.com/PowerDNS_Bert/status/797075994079268864

> exact language will be, so don't take this as that text, but our CTO
> and CEO have both said that our position should be something to the
> effect that if there's a standard developed in the IETF that would be
> covered by the patent, we would not assert these rights.

That would be great!

> We think the performance and security of the DNS are important.
> That’s one of the reasons that we implemented measures like this years
> ago.  We’re supportive of it becoming more recognized in the standards
> community at this point.   We also appreciate Andreas Gustafsson's
> good work at Nominum in developing this technology.

Ralf's presence at many community events is also most appreciated. It is
good to be visible.

So I understand your clarification, and I should not only rectify my tweets
but my message here as well. 

	Bert

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Nov 2016 04:58:43 +0900

Hm.   First, I tend to agree with you that the IETF should not work
with companies that attempt to hinder progress by asserting patents.
I am disappointed, however, that you would suggest that Nominum is
such a company.  We've been active in the IETF since the company was
founded, and have produced many standards during that time.  As far as
I know Nominum has never made any obstructive claims about patents in
connection with our participation in the IETF.

As a Nominum employee, I became aware of this issue about a week ago,
and at that time our legal team was asked to submit an IPR
notification on this draft with terms of use.   I do not know what the
exact language will be, so don't take this as that text, but our CTO
and CEO have both said that our position should be something to the
effect that if there's a standard developed in the IETF that would be
covered by the patent, we would not assert these rights.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 15 Nov 2016 09:53:35 +0900

On Fri, Nov 11, 2016 at 04:33:54PM +0200,
 Andreas Gustafsson <[email-masked]> wrote 
 a message of 22 lines which said:

> A resolver that receives an RD=0 query for a name that is not
> present in the cache should respond with a referral.  In a two-cache
> resolver, the natural place to look for the data to include in such
> a referral is the delegation cache, since that is where referrals
> are cached.

Good idea, but it is not in the current draft.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 15 Nov 2016 09:55:50 +0900

On Thu, Nov 10, 2016 at 08:46:55PM +0100,
 Ondřej Surý <[email-masked]> wrote 
 a message of 32 lines which said:

> > There seems to be an assumption in this draft that the parent NS
> > records are always correct, but I would argue that this is not the
> > case.
> 
> Nope, I don't think this is an assumption of this draft

Yes, it is. Otherwise, what would be the point of using the NS in the
parent instead of the authoritative one?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 15 Nov 2016 09:52:06 +0900

On Fri, Nov 11, 2016 at 02:08:54AM +0900,
 [email-masked] <[email-masked]> wrote 
 a message of 41 lines which said:

> > 2) It will make debugging more difficult. With your two-caches
> > system, "dig @myresolver NS foobar.example" will retrieve the data
> > in foobar.example, while the resolver will use, when iterating,
> > the data from .example, which is not showed and I don't see a
> > standard way to retrieve it from the "delegation cache".
> 
> - The simplest mode for the client is recursive, since in this mode
>   the name server acts in the role of a resolver and returns either
>   an error or the answer, but never referrals.  (RFC 1034 Section
>   4.3.1)
> 

Sorry, but I do not see how your answer addresses my concern. (I was
talking of debugging, not normal use.)

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 15 Nov 2016 03:12:43 +0100 (CET)

----- Original Message -----
> From: "Stephane Bortzmeyer" <[email-masked]>
> Cc: "Bob Harold" <[email-masked]>, "dnsop" <[email-masked]>
> Sent: Tuesday, 15 November, 2016 01:55:50
> Subject: Re: draft-fujiwara-dnsop-resolver-update-00

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

Cheers,

---

From: 神明達哉 <[email-masked]>
Date: Mon, 14 Nov 2016 18:40:56 -0800

At Tue, 15 Nov 2016 03:12:43 +0100 (CET),

> doesn't mean they are necessarily more or less "correct" than

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

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 15 Nov 2016 04:21:05 +0100 (CET)

----- Original Message -----
> From: "神明達哉" <[email-masked]>
> Cc: "Stephane Bortzmeyer" <[email-masked]>, "Bob Harold" <[email-masked]>, "dnsop" <[email-masked]>
> Sent: Tuesday, 15 November, 2016 03:40:56

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

Cheers,

---

From: 神明達哉 <[email-masked]>
Date: Tue, 15 Nov 2016 10:13:42 -0800

At Tue, 15 Nov 2016 04:21:05 +0100 (CET),

> 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