Re: [OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)

[Michael Richardson <[e-mail]>]

Erik Kline <[e-mail]> wrote:
    > I asked on a DNS directorate + wg chairs sync earlier today and nobody
    > seemed to have in mind either (a) a single good reference nor (b) a
    > single good definition for a "geofenced name".

    > Perhaps we can begin by clarifying what it means to you?  In mind there
    > were two alternatives; roughly:

    >     [a] a name for which a DNS authoritative will hand out different
    > RRs depending on the client src IP (conceptual proxy for geolocation),
    > or

    >     [b] a name for which a DNS authoritative will either hand out some
    > RRs **or** return NODATA or some kind of error to others, as a function
    > of client IP.

    > Are either of those close to what you mean?

Both are intended.
Is my term "geofenced" wrong perhaps? Is this just a geolocation DNS?

Looking around at some documents, I found:
        https://datatracker.ietf.org/doc/draft-pauly-httpbis-geoip-hint/
and:    https://www.rfc-editor.org/rfc/rfc7871.html

RFC7871 speaks alot about the behaviour of the authoritative server without
ever calling it geolocation :-)
"Tailored response" is the closest I can gleam from that document, which I
agree is a more general term.

I could use that term and reference 7871.

here is how I would use it:
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/pull/15

I found the discussion in RFC7871 concerning DNSSEC a bit concerning.
It seems that the entire RRset needs to always be returned (so that DNSSEC
can verify), but if that is done, how is the reply tailored, since A/AAAA
records are not intended to be ordered (and bind9 is about to remove that option).

Here is my proposed text, in case you haven't used the link above yet:

-Due to the problems with different answers from different DNS servers, described above, a strong recommendation is to avoid using geofenced names.
+## Do Not Use Tailored Responses to answer DNS Names
+
+{{?RFC7871}} defines the edns-client-subnet (ECS) EDNS0 option, and explains
+how authoritative servers sometimes answer queries differently based upon the
+IP address of the end system making the request.
+Ultimately, the decision is based upon some topological notion of closeness.
+This is often used to provide tailored responses to clients, providing them
+with a geographically advantageous answer.
+
+When the MUD controller makes it's DNS query, it is critical that it receive
+an answer which is based upon the same topological decision as when the IoT
+device makes its query.
+
+There are probably ways in which the MUD controller could use the
+edns-client-subnet option to make a query that would get the same treatment
+as when the IoT device makes its query.  If this worked then it would receive
+the same answer as the IoT device.
+
+In practice it could be quite difficult if the IoT device uses a different
+Internet connection, a different firewall, or a different recursive DNS
+server.
+The edns-client-server might be ignored or overridden by any of the DNS infrastructure.
+
+Some tailored responses might only re-order the replies so that the most
+preferred address is first.
+Such a system would be acceptable if the MUD controller had a way to know
+that the list was complete.
+
+But, due to the above problems, a strong recommendation is to avoid using
+tailored responses as part of the names in the MUD file.




--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide