Also just about every IPv6 only network will have IPv4AAS to reach the legacy servers so the A records are need especially if you are also validating answers. Also the provide a fallback if the IPv6 path is broken. -- Mark Andrews
> On 14 Sep 2024, at 00:19, Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> > wrote: > > > If the A record is useless to a v6-only client, the client can drop it upon > receipt without requiring new signalling between the stub and the resolver. > > For multi-qtype to be the correct solution, I feel all the following need to > be true: > * The client would prefer to save 200 bytes in transit rather than get a > partial answer 20 ms sooner. > * Resolver support for multi-qtypes is mandatory in this context, so the > client can rely on it. > * The client requires direct access to the full flexibility of DNS. (A > limited-purpose gateway will not suffice.) > > There may be situations that meet all of these criteria. If so, it would be > nice to hear a bit about them. > > --Ben > From: Petr Menšík <pemen...@redhat.com> > Sent: Friday, September 13, 2024 6:25 AM > To: dnsop@ietf.org <dnsop@ietf.org> > Subject: [DNSOP] Re: HTTPS and SVCB queries with > draft-bellis-dnsext-multi-qtypes-08 extension > > Yes, I am aware the code has to support parallel queries anyway, in case > resolver does support optimizations. > > But my idea is not about how to reduce queries. What I though more about is > how to reduce unnecessary records put into answer. Which goes into some cache > usually. And putting unnecessary records into cache means less space remains > for actually useful records. > > I made a post into dnssd about it just now, but let's also make example here. > > - example.com HTTPS query, with additional AAAA query in EDNS. > > What we should put into answer is described at RFC 9460, paragraph 4.2 [1]. > > ; ANSWER > example.com 600 HTTPS 1 svc.example.net > ; ADDITIONAL > svc.example.net 1200 A 192.0.2.53 ; <-- this RR should be avoided > svc.example.net 1200 AAAA 2001:DB8::53 > > Is there any way with single HTTPS query, how to indicate to add only AAAA > records into additional section? Contrary to what RFC 9460 say? What would > ipv6 only connected client do with A record? Ignore it? But why it were sent > then? multi-qtypes can provide indication for that, as well as improved > efficiency in ideal cases. If there is other good way, can you point me to it? > > ; ANSWER > example.com 600 HTTPS 1 . > ; ADDITIONAL > example.com 1200 A 192.0.2.53 ; <-- this RR should be avoided also > example.com 1200 AAAA 2001:DB8::53 > > This is proposed the most common scenario. But has the same problem. Why both > A and AAAA are sent, when client can use only one of them? Should they waste > space in cache for no reason? How should resolver sending them know? > > Regards, > Petr > > 1. https://datatracker.ietf.org/doc/html/rfc9460#name-recursive-resolvers > >> On 13/09/2024 11:29, Philip Homburg wrote: >> History shows that if you introduce a new thing DNS, lots of implementations >> will do something wrong. So it is unlikely that the system will actually >> get more simple. >> >> There may be good reasons to introduce more complexity. But on its own, >> any new feature is not going to reduce complexity. > I carefully chosen my words. It will be easier to debug in common case, when > all answers are delivered in single response. Yes, the complexity of code > responsible will not be reduced, unfortunately. But to implement Happy > Eyeballs algorithm in common applications, we need some added complexity > anyway. We just need way to potentially reduce resources used in the future, > where it makes sense. > > Yes, somebody will likely made it wrong. I think it is up to DNS community to > make specs clear enough and then tell those individuals to fix their > implementation. If somebody is still not processing EDNS0 correctly, then > the time to fix that has passed 10 years ago. > > -- > Petr Menšík > Software Engineer, RHEL > Red Hat, https://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
