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,
--
Ondřej Surý -- Technical Fellow
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.s...@nic.cz https://nic.cz/
--------------------------------------------
----- Original Message -----
> From: "fujiwara" <fujiw...@jprs.co.jp>
> To: "Ondřej Surý" <ondrej.s...@nic.cz>
> Cc: "dnsop" <dnsop@ietf.org>
> Sent: Thursday, 10 November, 2016 18:27:14
> Subject: Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
> Ondrej.Sury-san,
>
>> From: Ondřej Surý <ondrej.s...@nic.cz>
>> 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?
>
> 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.
>
>> 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.
>
> 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 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.
>
> However, the overwrite does not happen always.
>
> --
> Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
