Hello Paul, thank you for your detailed comments. I reply to them in-line.
> --------------------------------------------------------------------- > - > DISCUSS: > --------------------------------------------------------------------- > - > > I have balloted DISCUSS to have a discussion, but I expect to update > my ballot to ABSTAIN. > > > > I find this document fails to cater to a proper audience. It is > giving some very basic advise (like have v4+v6 and have A+AAAA) but > then throws in a whole bunch of complexity where this theoretically > could be handled if not done. The initial drafts of the document were a relatively straight forward change to 3901, making very minimal changes and moving IPv6 to be as much required as IPv4. However, over the course of discussions in the WG it became clear that a lot of additional context is required by the WG to reach consensus. This was subsequently added to be able to converge towards consensus. > I feel this document also mixes up the transport of DNS packets and > their v4/v6 families, with the query type family (A/AAAA). Eg even if > it has no v6 connectivity, it can still resolve AAAA records for ipv4 > clients that are dual stack if there are v4 DNS servers in the > authoritative NS set. The document discusses A/AAAA records when it comes to delegation and authoritatives. And, for an, e.g., IPv4 client to be able to resolve a name, say test.example.com, example.com needs to have at least one authoritative NS that has an A record for its name as recorded in the NS records in the parent as well as in the apex of the zone itself. Furthermore, if the NS is in-zone, there must be A glue for the name in the parent, and if the NS is out-of-zone, the NS' zone must be resolvable via IPv4 as well. Otherwise, it is not signaled to the IPv4 recursive from the example that the IPv4 transport is available, and, even if it was available on the authoritative servers, DNS resolution would fail. > Every recursive DNS resolver SHOULD be dual-stack. > > On the public internet, I believe this warrants a MUST. Just like you > MUST have both A and AAAA records in the NS RRset. There are several use-cases (see also below) where this is not necessarily the case, and dual-stack DNS resolution can take place despite the host itself being, e.g., IPv6 only. > Hence, a recursive DNS resolver MAY be IPv6-only, if it uses > a transition mechanism that allows it to also query IPv4-only > authoritative DNS servers, or uses a configuration where it > forwards queries failing IPv6-only DNS resolution to a > recursive > DNS resolver that is able to perform DNS resolution over > IPv4. > > This MAY sounds like a "theoretically, possible, depending on the > phase of the moon, could be ipv6-only, but it is extremely > complicated to get this done right so you really SHOULD NOT do this". I would argue that this is not only theoretically possible. It is implemented in unbound (see also the unbound documentation here: https://nlnetlabs.nl/documentation/unbound/unbound.conf/ ; search for 'NAT64 operation). Furthermore, AS59645 runs anycasted unbound based DNS resolvers that are IPv6 only, but resolve IPv4 only zones via this feature using an equally anycasted PREF64. So far I have not observed any issues with that, and it really helped freeing some IPs. I also know that some larger ISPs are doing something similar for their regional recursors. So, given running code and active deployment, I would say that this is more than "theoretically, possible, depending on the phase of the moon". > Similarly, a recursive DNS resolver MAY be IPv4-only, if it > uses > a configuration where such resolvers forward queries failing > IPv4-only DNS resolution to a recursive DNS resolver that is > able to perform DNS resolution over IPv6. > > This goes against the earlier "Every recursive DNS resolver SHOULD be > dual-stack." precisely for the huge complexity of getting things > working properly. IIRC, there was prominent request during the WG discussion to provide full parity between AFIs; Specifically, if we allow IPv6 only resolvers given a fallback (see above), it was requested that IPv4 shall receive the same treatment, even though there are no such implementations for IPv4. As an individual, I would have no issue with not giving the same option to IPv4 here. It would also allow removing the whole forwarding discussion (in place due to the request to have parity of v4 and v6, as there is no implementation similar to the nat64 feature in unbound). However, as said, WG consensus required parity here, leading to the above text being added. > Furthermore, a stub DNS resolver has to rely on recursive DNS > servers discovered for the local network, > > We had a whole working group (ADD WG) on using non-local recursive > DNS servers, and we have applications doing DoT/DoH to remote DNS > servers (eg firefox) so I find this statement questionable. I see your point here. Even though, following discussions i had around 124, it seems like local discovery is still a major thing, especially on mobile systems in wifi. Would your concerns on this point be less if the text was rephrased as follows? Furthermore, a stub DNS resolver might rely on recursive DNS servers discovered for the local network, ... With best regards, Tobias -- My working day may not be your working day. Please do not feel obliged to reply to my email outside of your normal working hours. ----------------------------------------------------------------- Tobias Fiebig, Forschungsgruppe Internet Architecture (INET) Max-Planck-Institut für Informatik, Campus E14, 66123 Saarbrücken E1 4 - Raum 517 mobil: +31 616 80 98 99 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
