Re: [DNSOP] [v6ops] New draft at dnsop a bis for DNS IPv6 Transport Operational Guidelines

[Momoka Yamamoto <[e-mail]>]

Thank you Geoff for your insightful clarification and the valuable data
presented in your article.

The alternative wording you suggest for draft 3901bis provides a balanced
approach.
It is more in line with the principle of minimizing potential harm while
maintaining operational efficiency.

We will incorporate your suggested wording with a reference to
draft-ietf-dnsop-avoid-fragmentation.

This draft intends to make DNS possible with IPv6, and with Geoff's
wording, I think we should be able to make IPv6 a SHOULD safely.
We do not want to make bad recommendations and this is very critical.
Thank you all for the discussion.
If there are still parts that should be done, please give us your input.

Momoka Y

On Fri, Nov 24, 2023 at 9:17 AM Mark Andrews <[e-mail]> wrote:

> There are a number of issues involved here
>
> Anycast DNS servers and blocking of PTB breaking PMTUD for both TCP and
> UDP.
>
> 1) set a lower MSS for TCP (e.g. 1280) so the replies don’t generate
> PTBs.  TCP
> retransmission timers are much too big for DNS.  The TCP sessions are torn
> down
> if there is no response in a couple of seconds.
> 2) set IPV6_USE_MIN_MTU=1 so that UDP packets are fragmented at network
> minimum MTU.
>
> BIND does both of these by default. Other servers do one or the other,
> both or none
> of these measures.
>
> Get firewall vendors to permit fragments from the reversed src/dst pairs
> when setting
> up connection tracking using the same expiry timers that they are using
> for the non
> fragmented responses.  IPv6 has a 32 bit fragment id which makes off path
> fragmentation
> reassembly attacks very hard for IPv6.  Alternatively just permit
> fragments.  They
> should be doing this independently of DNS.
>
> Servers should have a pool of multiple non sequential fragmentation
> identifier sources
> which are randomly selected from based on destination address.
>
> The reason for the draft is that DNS queries are being made from behind
> NAT64’s and
> that puts a lot of state there if there aren’t IPv6 servers available.
>
> Recursive DNS servers track RTT, preference IPv6 servers and use sub
> second timeouts
> when talking to the set of server addresses for a zone.
>
> As for EDNS advertised UDP size servers can restrict the response size
> independently
> of the client’s advertised response size if they want.  It comes at a cost
> of more TCP.
>
> Mark
>
> > On 24 Nov 2023, at 06:07, Geoff Huston <[e-mail]> wrote:
> >
> >
> >
> >> On 24 Nov 2023, at 5:37 am, Havard Eidnes <[e-mail]> wrote:
> >>
> >>> Go read https://www.potaroo.net/ispcol/2023-11/dns-ipv6.html to
> >>> get a clearer explanation of the issues here about the DNS, UDP
> >>> and IPv6.
> >>
> >> OK, I've done that, and I'm not entirely certain that I fully
> >> agree.
> >>
> >> ...
> >
> > Thanks for the thoughtful response Havard.As a minor point of correction
> the data
> > in that article is not a census of individual resolvers, but a census of
> users. i.e. if a resolver
> > is used by 100 users and another is used by just a single user the data
> will be weighted in
> > favour of the heavily used resolver.
> >
> > So the current data shows that some 69% of users pass their queries to a
> recursive
> > resolver over IPv6 use an EDNS buffer size that is greater than 1232
> bytes,
> > and 49% use a buffer size that is greater than 1500. In these cases the
> > odds of encountering a timeout rather than a response for large responses
> > is considerably higher. What this means is that it takes more time to
> resolve the name
> > (1 second is the most commonly observed timeout).
> >
> > So why should the IETF be proposing in a normative SHOULD the adoption of
> > an operational configuration that results in cases of slower response
> and an elevated
> > set of retransmissions?  To quote RFC2119:
> >
> > "[SHOULD] MUST only be used where it is actually required for
> interoperation
> > or to limit behaviour which has potential for causing harm (e.g.,
> limiting
> > retransmissions)"
> >
> > As I said in the article (
> https://www.potaroo.net/ispcol/2023-11/dns-ipv6.html) I offerred an
> > alternative wording for this 3901bis draft along the lines of:
> >
> > In using IPv6 as the platform for DNS queries, DNS implementations SHOULD
> > use an EDNS Buffer Size value of 1,232 bytes. An operator MAY use a
> greater
> > value for this parameter, but only if the DNS operator is confident that
> this
> > local setting will not result in IP packet fragmentation being required
> to pass
> > a DNS message to its intended recipient.
> >
> > If the reduced EDNS Buffer Size parameter is used by a DNS resolver,
> then such
> > DNS resolvers MAY order the list of servers that could be queried to
> prefer to
> > use an IPv6 query as the initial query.
> >
> > That would prevent the client performing a timeout and in the case of a
> large response
> > would allow the client to commence a TCP re-query within a single RTT.
> >
> >
> > regards,
> >
> >   Geoff
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]              INTERNET: [e-mail]
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>