[dns-operations] Using all the addresses of every name server? (Was: ANY efforts at taking additional responses more compact?

Viktor Dukhovni ietf-dane at dukhovni.org
Mon Sep 12 18:11:36 UTC 2016


> On Sep 12, 2016, at 12:11 PM, Fred Morris <m3047 at m3047.net> wrote:
> 
> On Monday 12 September 2016 08:36, Paul Vixie wrote:
>>> I would not recommend imputing any shared state across multiple
>>> addresses associated with a given name.  ...
>> 
>> that ship has already sailed, so, the expectation must remain reasonable.
> 
> I would assume that if shared state is reasonable across multiple addresses, 
> then it is reasonable for it to hold for single addresses. However the world 
> hasn't fallen over because, for example, 8.8.8.8 doesn't always return 
> consistent answers. It might help if you explained exactly what shared state 
> concerned you. Obviously TCP isn't assuming shared state: nobody's randomly 
> firing packets in a TCP stream at different addresses and expecting them to 
> get reassembled correctly. Servers can crash; I haven't see anything in the 
> specs about maintaining state across restarts.

What I meant by the shorthand "shared state" for multiple IP addresses of a
multi-address name, was that all the addresses share a single DNS nameserver
instance, such that above the network layer, identical failure modes can be
expected across all the addresses in question.

   * If any address returns lame delegations, all do
   * If any address refuses service, all do
   * If any address returns bogus replies, all do...

If one assumes such "shared state", one might not want to fail-over from
one address of a multi-address nameserver name to another...

I was exploring whether the "shared state" assumption is at all common,
and if not whether one could take advantage of multi-address names to
reduce the RRSIG count in the additional section...  Note, I was not
and am not arguing for or against the validity of this view.  Just
asking questions.

-- 
	Viktor.





More information about the dns-operations mailing list