On Tue, Mar 5, 2024 at 3:26 PM Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > 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.
If this is the recommendation that has consensus then I think this definitely explains the intention more clearly, thank you. That said, it seems to me to be akin to saying "don't use a CDN", or at least don't use them the way most CDN services are configured. I'm not sure how this will be received by folks who should be reading and considering these things. Still, including it as RECOMMENDED seems fine to me. It tells the reader "here be dragons" and sets out the rationale. Thanks. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
