Re: [OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
Erik Kline wrote: >> Here is my proposed text, in case you haven't used the link above yet: ... > If this is the recommendation that has consensus then I think this > definitely explains the intention more clearly, thank you. I guess I need to wait a few days to hear back from the WG and other reviewers. I should repost to m...@ietf.org, which I'll do in a second. > 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. Yes, the goal is to have some BCP that sets out some things that work better. I did run this document by a few CDN people and they seemed okay. Of course, things could get better, and we could revise the document. Use a CDN if you need to, I think that there are some reasonable ways to do configure things for it. If this document helps CDNs and users of CDN align their offerings better, than that's a good thing. In this case having an A/ record that just always has *all* the possible geolocation/tailored-response answers would work really well. Like: all.upgrades.example.com -- all possible names (put into MUD file) upgrades.examples.com-- tailored response name (put into firmware) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
On Tue, Mar 5, 2024 at 3:26 PM Michael Richardson wrote:
>
>
> Erik Kline 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/
> 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
Re: [OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
Erik Kline 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/
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. 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
Re: [OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
On Mon, Mar 4, 2024 at 8:53 AM Michael Richardson wrote: > > > Erik Kline via Datatracker wrote: > > ## Comments > > I got your nits in my copy. > > > * I suggest finding some text to point to that defines what a > > "geofenced" name is. Right now this feels like the kind of thing that > > everyone "just knows what it means", but could use some formal > > description. > > Ugh. I don't think we have any RFC that defines it. It's not in 8499bis. > Maybe someone else has an idea for a good reference. 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? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
Erik Kline via Datatracker wrote: > ## Comments I got your nits in my copy. > * I suggest finding some text to point to that defines what a > "geofenced" name is. Right now this feels like the kind of thing that > everyone "just knows what it means", but could use some formal > description. Ugh. I don't think we have any RFC that defines it. It's not in 8499bis. Maybe someone else has an idea for a good reference. -- Michael Richardson. 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
