Re: Some thoughts/comments on draft-gont-6man-slaac-dns-config-issues-01

[Mark ZZZ Smith <[e-mail]>]

Fernando suggested I should have also CC'd 6man for further discussion/comments.
      From: Mark ZZZ Smith <[e-mail]>
 To: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]> 
Cc: "[e-mail]" <[e-mail]> 
 Sent: Thursday, 16 April 2015, 16:22
 Subject: Some thoughts/comments on draft-gont-6man-slaac-dns-config-issues-01
   
Hi,

CC'ing Mark Andrews, because he is one of the DNS experts I'm aware of, so it would be good to get his input.

I'm having a read though, here are some thoughts/comments I have on it. Pay attention to or disregard at will!



1.  Introduction~~~~~~~~~~~~~~~

Regarding this discussion:

"The recommended bounds (MaxRtrAdvInterval <=
Lifetime <= 2*MaxRtrAdvInterval) have been found to be too short for
scenarios in which some Router Advertisement messages may be lost.
In such scenarios, hosts may fail to receive unsolicited Router
Advertisements and therefore fail to refresh the expiration time of
the DNS-related information previously learned through the RDNSS and
DNSSL options), thus eventually discarding the aforementioned DNS-
related information prematurely."


I think the more important thing to point out is that, as per RFC4861, Router Lifetime,

"The Router Lifetime applies only to
the router's usefulness as a default router; it
does not apply to information contained in other
message fields or options."

and, 

"Options that need time limits for their information include their own
lifetime fields."

which means that option lifetime values are or should be independent of the Router Lifetime value and its upper or lower value constants (e.g MaxRtrAdvInterval)
 
In other words, state that the RDNSS and DNSSL lifetimes should have never been derived or limited to the RAs Router Lifetime value, and also observe that what has been specified in RFC6106 has caused the issues mentioned.


2.  Changing the Semantics of the 'Lifetime' field of RDNSS and DNSSL options
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


I'd suggest adding (enclosed in **s)

"o  The 'Lifetime' field indicates the amount of time during which the
aforementioned DNS-related information is expected to be stable.
A node is NOT required to discard the DNS-related information once
the Lifetime expires. ** The RDNSS and DNSSL Lifetime field values are now completely independent of the RA's Router Lifetime field value. ***"

to make this independence very clear.

I think it would also be worth pointing out, perhaps as a second paragraph to this point, that the DNS resolver in the client will take actions to deal with unreachable DNS servers, in the case where the DNS information hasn't been discarded despite the RDNSS option lifetime having expired. In other words, the RDNSS lifetime value is not the absolute indication of whether a DNS server is useful or not, and the resolver will determine that by actively attempting to use the DNS server. Perhaps that means that the text should be changed to 
"A node is SHOULD NOT discard the DNS-related information once the Lifetime expires."? (which I suppose almost makes the RDNSS option lifetime value redundant?!)





"o  If a host has already gathered a sufficient number of RDNSS
addresses (or DNS search domain names), and additional data is
received while the existing entries have not yet expired, the
received RDNSS addresses (or DNS search domain names) SHOULD be
ignored."

I don't think the same rule for RDNSS can be also applied to the DNSSL options.

In the case of RDNSS, the assumption would be that all of the DNS servers supplied in the RDNSS option can provide equivalent DNS resolution service. For example, ignoring 2 out of 5 should not cause any issues, because the remaining 3 should provide equivalent service to the ignored 2.

However, for DNSSL, I think ignoring some of them might cause failures, because the options are not providing equivalent values. For example, say DNSSL:example.com and DNSSL:example.org were accepted, but DNSSL:example.net was ignored. If 'www' was looked up, and 'www.example.net' was the only entry that should have matched, ignoring DNSSL:example.net would cause a lookup of 'www' to fail to match on 'www.example.net'. I think the resolver would then do a root lookup of 'www.' and that would either fail too or return something not intended.



"o  If a host receives new RDNSS addresses (or DNS search domain
names), and some of the existing entries have expired, the newly-
learned information SHOULD be used to replace the expired entries."
I think similar to above applies, different newer DNSSL option values aren't replacements for older, expired DNSSL option values. Expired DNSSL options should probably be thrown away when they expire.




"o  A host SHOULD flush configured DNS-related information when it has
any reason to believe that its network connectivity has changed in
some relevant way (e.g., there has been a "link change event").
When that happens, the host MAY send a Router Solicitation message
to re-learn the corresponding DNS-related information."

Perhaps another signal to trigger this could be repeated failed attempts by the DNS resolver to use the majority or probably all of the existing DNS server IPv6 addresses?




3.  Changing the Default Values of the 'Lifetime' field of RDNSS and DNSSL options
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Firstly, this is probably also a section where pointing out that the DNS resolver will make its own liveness tests/attempts to overcome the sorts of packet loss mentioned.

Regarding this,

"
[RFC6106] is hereby updated as follows:

The default value of AdvRDNSSLifetime and AdvDNSSLLifetime MUST be
at least 10*MaxRtrAdvInterval so that the probability of hosts
receiving unsolicited Router Advertisements is increased."



I'm in two minds. On the one hand, I like the idea of having an automated default that is relative to the perceived level of packet loss that might occur. On the other hand, as before, Router Lifetime and its upper and lower limits are not general "whole of RA" lifetime constraints or RA robustness parameters.

Perhaps the middle ground would be to define a specific constant and then note that it is the 10 times the value of MaxRtrAdvInterval,  specified in RFC4861. This would allow the specific constant to be changed at a later time if necessary, or allow the operator to change the value, without being constrained to it being 10*MaxRtrAdvInterval (that is, if it is defined as a formula, then in code it probably wouldn't be made an independently settable parameter, it'd just be calculated based on the current value of MaxRtrAdvInterval).



4.  Use of Router Solicitations for active Probing~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I don't think the RDNSS and DNSSL RFC should have said anything about this, as more generally, the problem is one of RA robustness, independent of what particular options are in the RA. Theoretically, different RA options could define their own RA robustness methods that could end up being incompatible with each other.

So perhaps it might be better to say that RA robustness is not specific to RDNSS and DNSSL options, and refer to a more general mechanism, if it exists (?), regarding triggering RSes to seek new option values (hmm, I don't remember reading anything specific about it, but perhaps that means that RA option lifetimes are always greater than the unsolicited RA interval to ensure option lifetimes are always refreshed before they expire?)



5.  Sanitize the received RDNSS/DNSSL 'Lifetime' Values~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As per above and other RA options, a constant upper limit would be better.




Regards,
Mark.