Erik Kline <ek.i...@gmail.com> 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
