Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09
Michael Richardson wrote: > definition which was objected to by multiple IESG members. > https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/ballot/ > (in RFC-editor Q, on missref) > So, if you didn't like that definition before, then probably you should > object to RFC8499bis keeping it. Ted's original review that lead to this: https://mailarchive.ietf.org/arch/msg/dnsdir/Ev83RjCbQcC64paenZXJawKxu9k/ -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09
I also want to note that rfc8499bis contains the same "Domain Name" definition which was objected to by multiple IESG members. https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/ballot/ (in RFC-editor Q, on missref) So, if you didn't like that definition before, then probably you should object to RFC8499bis keeping it. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnssd] Solicit feedback for the DNS behavior for workloads hosted in Cloud DCs described in draft-ietf-rtgwg-net2cloud-problem-statement
This sounds a bit like the provisioning domain DNS problem. I felt that PvD was IPv4 think applied to DNS. I strongly agree with you recommendation: > Globally unique names do not equate to globally resolvable names or even > global names that resolve the same way from every perspective. Globally > unique names can prevent any possibility of collisions at present or in the > future, and they make DNSSEC trust manageable. Consider using a registered > and fully qualified domain name (FQDN) from global DNS as the root for > enterprise and other internal namespaces. Do a zone cut for cloud.example.net, put up some NS records for that, and then answer queries only when the question comes from authorized cloud providers. The answer might well be ULAs that only work within the VPN, or RFC1918 even. I wrote a document awhile ago suggesting this: https://datatracker.ietf.org/doc/html/draft-richardson-homenet-secret-gardens-01 but, MIF shutdown before I could take it anywhere. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] automating RFC2317 via IPv6 reverse map/DHCPv6
Havard Eidnes wrote: >> Hi, while editing draft-ietf-homenet-front-end-naming-delegation, it occured >> to me that the automatic reverse that >> draft-ietf-homenet-naming-architecture-dhc-options could enable >> better/simpler RFC2317 delegation for IPv4 subnets. >> >> My experience is that some of the pushback for doing 2317 is that there is >> sane way to automate it, and too many confusing ways to do it. >> >> So, I wrote: >> https://datatracker.ietf.org/doc/draft-richardson-ipv4-reverse-in-v6/ >> >> which basically says to point the CNAMEs into the IPv6 delegation that is >> "already" (will have been) being done. > The actual convention to use isn't really specified by 2317, only > a few examples are given. This one should work just as well as > any other convention, and if this makes it easier to use, I'm all > for it. Yes, the lack of a convention in 2317 was something that I noticed, and thought wait... what if we adopted *this* convention. (I see no point in proceeding with this document until the homenet documents are in RFC editor Q. Of course, as there are no IANA actions, and it's just a update to a convention, it could be implemented now) Tim Wicinski wrote: > Some time back Tony Finch proposed a 2317bis - > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2317bis-00 > which the WG adopted but died for lack of interest. > It would be useful to revise this document Thank you for the pointer. It got enough interest to get adopted... the document looks like it could just be WGLC'ed. My suggest convention into the ip6.arpa tree could be combined in, and probably the first-last convention could be also be used. (and it sounds like Vixie thinks the document should/could go ahead) signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] automating RFC2317 via IPv6 reverse map/DHCPv6
Hi, while editing draft-ietf-homenet-front-end-naming-delegation, it occured to me that the automatic reverse that draft-ietf-homenet-naming-architecture-dhc-options could enable better/simpler RFC2317 delegation for IPv4 subnets. My experience is that some of the pushback for doing 2317 is that there is sane way to automate it, and too many confusing ways to do it. So, I wrote: https://datatracker.ietf.org/doc/draft-richardson-ipv4-reverse-in-v6/ which basically says to point the CNAMEs into the IPv6 delegation that is "already" (will have been) being done. Anything we can do to make those who need just a bit of IPv4 (one or two addresses) easier, while encouraging IPv6-first, is a good thing to me. Your comments much appreciated. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RFC9103 -- extended key usage
https://www.ietf.org/rfc/rfc9103.html#name-mutual-tls tells me how I could use mutual TLS to authenticate (and I think, authorize) a zone transfer. What it does not tell me is whether there should be any Extended Key Usage bits set on the certificates. Are the WebServer/WebClient required? forbidden? tolerated? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Protocol Action: 'DNS Security Extensions (DNSSEC)' to Best Current Practice (draft-ietf-dnsop-dnssec-bcp-06.txt)
What a great document. I would like more WGs to do this kind of thing regularly. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [BEHAVE] [v6ops] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt
Geoff Huston wrote: >> On 17 Oct 2022, at 7:53 am, Michael Richardson wrote: >> I think that's because >> recursive nameserves effectively have always done an equivalent to "happy >> eyeballs", so the risk is low. > That certainly was not the case in 2015: https://www.potaroo.net/presentations/2015-10-04-dns-dual-stack.pdf > I have not seen a large scale measurement since then but I suspect that nothing has changed. i.e.: > recursive resolvers do not do the equivalent of happy eyeballs > behaviour. What I'm saying (based upon my understanding, and some long ago reading of code) is that recursive nameservers remember which NS were too slow or non-functional, and try to avoid them in the future. (I agree that this isn't exactly happy eyeballs: we don't do requests in parallel and pick the winner) So if my v6 infrastructure for my authoritative nameservers fails, but the v4 continues to work, that I'm not too badly off. My experience is that this resilience can often mask failed servers for months :-) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [BEHAVE] [v6ops] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt
Joe Abley wrote: > My feeling is that it's far more common to find dual-stack nameservers > reachable directly by v6-only and v4-only clients than it is to find > services that the requested names refer to that are dual-stack and > similarly reachable. On the face of it this seems like the opposite > assumption than the one you describe above. I would say the same thing. DNS operators (whether outsourced or on-prem), seem way more proactive about v6 support than other parts of organizations. I think that's because recursive nameserves effectively have always done an equivalent to "happy eyeballs", so the risk is low. There are exceptions: ipv6.bell.ca is one. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Mud] looking for reference for reverse maps do not work
Andrew Sullivan wrote: > I tried to document this ages ago in > https://datatracker.ietf.org/doc/draft-ietf-dnsop-reverse-mapping-considerations/, > and got so many contradictory edits (see the history) that the final > version ended up saying “A or maybe not-A, or maybe both, your choice,” > so the then-chairs decided the document wasn’t worth sending through > publication. Oh. That's why I don't want to attempt writing this myself. So, that's not encouraging. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] looking for reference for reverse maps do not work
Hi, in reviews of https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-04.html I was asked to expand upon why the reverse map can not be intelligently used for MUD ACLs. (section 3, XXX stuff) (MUD controllers, upon being presented with ACLs made up of names need to do forward lookups of the names and build ACLs based upon the IP addresses.) There are two aspects of this: 1) even in an ideal situation, it takes too long on the first packet to extract a name from an IP address. Yes, that could be aggresively cached. 2) forward:reverse maps are N:M mappings, often with unidirectional parts, and often broken or not delegated. Further, there is no authorization of the mappings, so an attacker who wants to be able to reach IP address 2001:db8::abcd, can insert a reverse name of their choice, including updates.example.com, which is permitted by the MUD ACL. While I can write the above paragraph, I don't feel that it's detailed enough for what is needed, and I feel that we (the IETF) must have documented the security issues with reverse/forward mismatched at least twice over the past 40 years. I'm looking for a good well reviewed reference to use rather than repeating this again. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] MUD in DNSOP (fwd) Ben Schwartz: MUD in DNSOP
Forwarding comments. <#secure method=pgpmime mode=sign> --- Begin Message --- I noticed that draft-ietf-opsawg-mud-iot-dns-considerations is on the DNSOP agenda for this week. It considers the problem of using MUD, which applies IP-based filtering to locked-down IoT devices, with DNS-named servers. Some of the recommendations are clearly correct given the limitations of MUD, but I also have significant concerns with parts of the text. Section 4.1 says not to use IP addresses at all. Section 5 and Section 6.4 make recommendations about which resolvers to use for IoT generally. I think this is not necessary or productive. The recommendations should be limited to MUD-DNS devices. The draft recommends that devices use the network-provided DNS server, which is typically a general-purpose resolver that is capable of processing any name. Allowing the device to access this server defeats much of the security benefit of MUD, because malware can communicate bidirectionally through the DNS server, bypassing the MUD profile entirely. It would be more secure to disable the urn:ietf:params:mud:dns permission. Section 6.3 says When aliases point to a Content-Distribution Network (CDN), prefer to >use stable names that point to appropriately load balanced targets. >CDNs that employ very low time-to-live (TTL) values for DNS make it >harder for the MUD controller to get the same answer as the IoT >Device. A CDN that always returns the same set of A and >records, but permutes them to provide the best one first provides a >more reliable answer. I don't think this guidance is sufficient. MUD's DNS filters assume that the device and gateway have the same answer in their local caches. Even if the device got its answer _through_ the gateway, there's no guarantee that this is true, unless the name always resolves to the same addresses. Even if the name resolves to the same addresses for everyone (no geotargeting or load-balancing), any change to the zone can result in a device-gateway mismatch during the transition, resulting in an outage while the gateway blocks the device's network access. This mismatch can last for the duration of the DNS TTL. Ironically, the guidance here to use long TTLs could result in longer outages, plausibly hours to days. Even if the device always delegates DNS resolution to the MUD gateway, and the gateway attempts to provide deterministic caching (unlike a typical resolver or forwarder), consider the case where the gateway experiences a power glitch and resets. Normally, with MUD, this would likely result in an outage of less than a minute, but if the gateway re-queries the DNS name and gets a new answer, all corresponding devices on the network will be offline for the DNS TTL. I want MUD-DNS to work, but I think that's going to require some deeper changes. The cleanest solution, in my view, would be to avoid the device ever learning about the results of DNS resolution, by forwarding traffic to named destinations through a SOCKS5 proxy operated by the gateway. (SOCKS5 is trivial to implement, far simpler than DNS.) A similar effect could be achieved by IP encapsulation, IPv6 extension headers, and many other mechanisms. A hackier solution would be to add a DHCP option for the MUD gateway to specify its associated resolver, and require devices not to implement any DNS caching. These approaches are compatible with disabling the urn:ietf:params:mud:dns permission, which is typically necessary for real control over the device. --Ben [1] https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-01.txt smime.p7s Description: S/MIME Cryptographic Signature --- End Message --- -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSA says don't use public DNS or DoH servers
On 2021-01-18 4:27 p.m., John Levine wrote: They think DoH is swell, but not when it bypasses security controls and leaks info to random outside people Sage advice. In the OPSAWG where RFC8520 (MUD) currently lives, we are trying to codify advice to to IoT manufacturers about these things. please see recently adopted: draft-ietf-opsawg-mud-iot-dns-considerations-00 The -01 coming out next week with many clarifications. Most of the advice is of the form, "Doctor it hurts when I poke myself in the eye", but there is a real tussle between shipping devices that work even when the "luser" (or their monopoly ISP) has toasted their local recursive server, vs privacy vs RFC8520 ACLs. In fact, the reason I opened up the IMAP to dnsop (which I haven't time to read regularly, sorry), is because I wanted to ask to present at IETF110, with the hope of getting some additional review. (I understand this WG decided not to standardize the term "QuadX", and I would dearly like an equally terse replacement) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [homenet] Montreal homenet activities -- front-end-naming
Normen Kowalewski wrote: > apologies for this really very late reply, but FAIW it's IMHO not > really a "Synchronization Server", because the flow is really > hierachical - from home via the to-be-named-entity, and then to the > place tha scales out, like the slaves of that entity. I think it is > also not really a “Distribution Server", if the collecting > to-be-named-entity is a fully grown-up DNS Auth by itself, in which i > can/do also manage zones directly. I never liked "Synchornization Server", and we removed that term. We settled on Distribution Master, which is usually the stealth primary, and transfers zones to the public secondaries. > When I ran things in a chain like this, it saw the to-be-named-entity > as acting in the capacity of a "DNS intermediary [master]", or "DNS > provisioning proxy". DNS intermediary Master, conveniently could also be abbreviated to "DM" :-) > AFAIK already when we starting the early discussions on this (Hi > Daniel, Hi Ralf!) for the former expired draft, we had not found a > specific terminology for such a use of nn DNS Authorittive Server in a > draft/doc anywhere, but i still think it is worth the effort to have a > specific term for that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [homenet] Montreal homenet activities -- front-end-naming
(context: The HOMENET WG will not meet in Montreal at IETF105) The HOMENET front-end-naming design team will spend some unstructure time together. This relates to https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ The exact time is to be determined as the unstructured schedule has yet to be determined. Tentatively, I want to suggest an hour on Tuesday morning. We would love to spend some time with people who design and/or operate public anycast DNS systems. We want to make sure that we match any terminology that you use, and to learn about practical limitations that we might be unaware of. This in particular relates to the questions at: https://mailarchive.ietf.org/arch/msg/homenet/VcXftoB30feY9PlsPtvEV65JycM -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] front-end naming document: Synchronization Server
Last week Daniel and I resurrected https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ The -08 version was posted, it should have minimal changes for the expired -07 version, except that this version is done in Markdown/github, etc. Issues tracked are at: https://github.com/ietf-homenet-wg/ietf-homenet-hna (please ignore similar named repo which was duplicated) The -09 version will include significant changes, and we posted -08 to be sure that all changes were intentional. I include the abstract below for the benefit of people who are BCC'ed. The essential architecture is a stealth primary running in the homenet (likely in one of the CPEs), using a zone-transfer to "cloud" hosted primary server (A), and likely from there to a typical set of authortiative servers. These might be anycast'ed or not, depending upon who is running the service. The question I have for this email is whether or not there is a common name for the primary server (A), which collects the zones from the stealth primary server. That server is often not publically listed. In the document, it was called the "Synchronization Server", but I don't think that is a good name. In my previous experience doing this kind of thing the server A was called the Distribution Server. While I like that term better, I don't know how common it is for other DNS providers. So what term do you know of? Has the architecture of having a stealth primary feeding a distribution server, which then transfers to some set of public facing servers been formally described in an IETF document? If not, in some OARC document? Abstract Designation of services and devices of a home network is not user friendly, and mechanisms should enable a user to designate services and devices inside a home network using names. In order to enable internal communications while the home network experiments Internet connectivity shortage, the naming service should be hosted on a device inside the home network. On the other hand, home networks devices have not been designed to handle heavy loads. As a result, hosting the naming service on such home network device, visible on the Internet exposes this device to resource exhaustion and other attacks, which could make the home network unreachable, and most probably would also affect the internal communications of the home network. As result, home networks may prefer not serving the naming service for the Internet, but instead prefer outsourcing it to a third party. This document describes a mechanisms that enables the Home Network Authority (HNA) to outsource the naming service to the Outsourcing Infrastructure. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] front-end naming document: Synchronization Server
Last week Daniel and I resurrected https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ The -08 version was posted, it should have minimal changes for the expired -07 version, except that this version is done in Markdown/github, etc. Issues tracked are at: https://github.com/ietf-homenet-wg/ietf-homenet-hna (please ignore similar named repo which was duplicated) The -09 version will include significant changes, and we posted -08 to be sure that all changes were intentional. I include the abstract below for the benefit of people who are BCC'ed. The essential architecture is a stealth primary running in the homenet (likely in one of the CPEs), using a zone-transfer to "cloud" hosted primary server (A), and likely from there to a typical set of authortiative servers. These might be anycast'ed or not, depending upon who is running the service. The question I have for this email is whether or not there is a common name for the primary server (A), which collects the zones from the stealth primary server. That server is often not publically listed. In the document, it was called the "Synchronization Server", but I don't think that is a good name. In my previous experience doing this kind of thing the server A was called the Distribution Server. While I like that term better, I don't know how common it is for other DNS providers. So what term do you know of? Has the architecture of having a stealth primary feeding a distribution server, which then transfers to some set of public facing servers been formally described in an IETF document? If not, in some OARC document? Abstract Designation of services and devices of a home network is not user friendly, and mechanisms should enable a user to designate services and devices inside a home network using names. In order to enable internal communications while the home network experiments Internet connectivity shortage, the naming service should be hosted on a device inside the home network. On the other hand, home networks devices have not been designed to handle heavy loads. As a result, hosting the naming service on such home network device, visible on the Internet exposes this device to resource exhaustion and other attacks, which could make the home network unreachable, and most probably would also affect the internal communications of the home network. As result, home networks may prefer not serving the naming service for the Internet, but instead prefer outsourcing it to a third party. This document describes a mechanisms that enables the Home Network Authority (HNA) to outsource the naming service to the Outsourcing Infrastructure. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.
Terry Manderson <terry.mander...@icann.org> wrote: > B) seek a .homenet special use domain WITHOUT the delegation request > AND ask the IETF/IESG/IAB to commence the discussion with the ICANN > community to achieve an insecure delegation > c) seek a .arpa insecure special use delegation > d) go for "B" and if that doesn't work shift to "C" Is there some reason we can not proceed with "C", concurrently with (B). This might cause stub resolvers to have to have two cases (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy and attempt interop with SOMETHING.arpa NOW, and it would more clearly permit "home." to be removed from code. > Again, this situation is fluid and as discussions evolve I will provide > more information when it is appropriate. In the mean-time I would very > much like everyone to take a calming breath and understand that I am > taking a very pragmatic view of this concern. Thank you! -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [homenet] ip6.arpa reverse delegation
Markus Stenberg markus.stenb...@iki.fi wrote: On 23.11.2014, at 23.14, Michael Richardson mcr+i...@sandelman.ca wrote: I have read: Automated Delegation of IP6.ARPA reverse zones with Prefix Delegation draft-andrews-dnsop-pd-reverse-02 as a method to delegate reverse zones to CPE devices as the prefix is delegated. I find the method entirely sensible, and I think highly secure. I don't know if this belongs in dnsop or in homenet (or dhcpv6, since a new DHCPv6 option is requested, and this enhances DHCPv6-PD): I'll let the INT and Ops ADs sort that out. Is this actually desired by the operators? At least here (.fi), ISPs I don't care what they want: I want it as a customer. At this point, one can not originate email from IPv6 addresses without working reverse names. I don't care if some operators do not want to deploy, and I don't care if some customers can't be bothered to setup or or own their reverse map. Nobody is forcing anyone to do this; (or to run IPv6). But, if someone wants to delegate the reverse (and I know many operators who do), this seems like the right way to do it. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ pgpRczj8wNZ8g.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
