Tommy Jensen <[email protected]> wrote: > Another draft, unrelated to my feelings for Classic DNS over UDP.
> David, John, and I wrote this draft which defines a way to associate IP
> prefixes with a domain name. This is somewhat reminiscent of the
> experimental APL record (RFC 3123) with more specific structure and
> intent.
This I-D was discussed yesterday on Andrew's encrypted-DNS focus group.
I read the I-D today. I think that this problem definitely needs solving,
but I'm not sure this is the right way. The I-D should probably reference
the various Protective DNS mechanisms that Microsoft and Adamnent have worked
on.
(I can't say how weird I find the 9000 in RFC9000 is... decades of xx00
being summary RFCs burnnt into my brain)
RFC9726: Operational Considerations for Use of DNS in Internet of Things (IoT)
Devices
(I should have gotten "MUD" into the title)
RFC9726 is about MUD + DNS and addresses, and it should be referenced,
perhaps even updated. A solution would definitely help!
In particular, this might allow for better tailored responses ('geofenced'),
with the CIDRS RR providing the complete list of possible destinations.
A critical bit to understand about 9726 and dnsop-associated-prefixes is that
security clue is a critical (human) resource, and every single false positive
has a major impact. False positive to remind: when a security alarm goes
off, but it's not actually a problem.
Too many, and the alarm gets turned off/ignored.
(BTW: "Boy who cried wolf" got eaten by the wolf)
4.1 should probably emphasis that there might be many CIDRS RRs.
MANY. So I have a fall-back-to-TCP/EDNS0-fragment concern...
4.1.3 goes into this a bit, and 5.2 as well, I see.
(I had a list of Cisco Webex teams prefixes that I found I had to route
specially, because webex teams could not cope with public IPv4/IPv6, only
NAT44. That problem seems to have gone away. The list was 47 entries long,
consisting of /19s and /20s. That's a *LOT* )
5.1 says:
Note that associated IP addresses SHOULD be restricted to IP
addresses which a server reasonably expects a client will need to
interact with the functionality provided by the service which uses
the domain name. For example, name owners SHOULD NOT create CIDRS
records that include all IP ranges owned by a company for the
company's primarily recognizable domain name (example-
company.example. having a CIDRS record listing every IP address owned
by Example Company would be inappropriate).
For services that dynamically deploy to public clouds, adding servers as they
need more capacity, the incentive is going to be just list all the address
space for the public cloud (e.g. 52.30.0.0/15...).
The video streaming companies come to mind, yet, keeping TVs from attacking
the root name servers seems like a good thing.
So I'm particularly concerned about the TTL on these records.
1. I also wonder, given that 47 CIDRS RRs seem like a lot, if the DNS is the
right place to put this. I don't think it's an outlier.
*maybe* a .well-known resource might be a better way to do this.
OTH, for DoT/DoH, it's not that much data to stream back over TLS/TCP.
2. Regardless of #1, it might be worth signaling in DNS, either in the A/AAAA[%]
reply, or the SVCB reply, that an associated CIDRS list is available. I'm
not sure
if EDNS or OPT or what would work best.
> The basic idea is there are services identified by a domain name that
> trigger network traffic being sent to IP addresses other than those in
> existing DNS RR types. A common example is the use of WebRTC by a
> program that uses teleconferencing[.]vendor[.]example for initial
> connections, but ends up streaming to IP addresses not discovered via
> the DNS. QUIC also supports servers migrating clients to preferred IP
> addresses which may not be present in the DNS. Such vendors tend to
> document their required IP prefixes for firewall configuration
> purposes, but this leads to manual labor by sysadmins to accumulate
> these, possibly with vendor lock-in mechanisms.
> This document intends to make that process automatic: instead of
> tracking separate vendor's documentation or APIs, accumulation of
> addresses associated with a service is via DNS queries for the vendor's
> domain names, which do not tend to change frequently.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
