[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dns-operations
Subject:    Re: [dns-operations] resimprove and Re:  DNS Flush Protocol
From:       Edward Lewis <edward.lewis () icann ! org>
Date:       2015-04-02 14:38:13
Message-ID: D142C4D8.A8FB%edward.lewis () icann ! org
[Download RAW message or body]

On 3/31/15, 13:49, "Paul Vixie" <paul@redbarn.org> wrote:

> the descendant's apex NS TTL has a higher credibility.

A nit - RFC 2181 uses trustworthiness, not credibility.  I had to "fix"
that in my discussions on the topic.  (Trying to stem terminology creep.)

>if you have an alternative in mind that uses some other existing
>transaction (like the delegation's TTL) then it could scale to the size
>of the current and future internet, and in that case i'd like to hear
>your thoughts.

I wouldn't propose such an alternative.  I don't think building on an
'existing transaction' will stand the test of time.

In brief, twisting a unused element of the protocol is something I'd be
cautious about.  (Such approaches have been tried before.)  Examples of
this have been round-robin ordering of records in a response, the 0x20
approach to reduce forgery of messages.  Sometimes this gets burned into
implementation and bites us later (round robin) and sometimes it doesn't
prove powerful enough (0x20).  I've not done comprehensive work on this
point, so, this is more feeling than proof.  The TTL of a record set is
meant to be an expectation of how long until it might change.  Using it
for other purposes triggers my ulcers.

The request to purge caches is not a function of the DNS protocol, it's a
function of the environment we operate in.  I don't see it needed in
private DNS set ups, and in other inter-networks there are controls to
reduce the need.  From this observation, I really wouldn't burn this into
the core protocol.  I prefer an external solution based on the
observations of how the Internet is put together(work /constantly/ in
progress) and on the observation that there's an apparent demand for a
control layer over the DNS.  (DNS 2.0 is Quixote's windmills, yes, there's
a more realistic chance of fixing the Internet's DNS environment.)

I don't think burning assumptions into the protocol about today's
situation and problems will benefit future situations.  That has backfired
before, it has made extending the protocol difficult.  (We seem to
increasingly assume that the global public Internet is the only use case
for DNS, which bothers me too.)

["smime.p7s" (application/pkcs7-signature)]

_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
--===============0431033670992810465==--

[prev in list] [next in list] [prev in thread] [next in thread]