Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-07.txt

[Paul Wouters]

On Tue, 27 Sep 2022, internet-dra...@ietf.org wrote:


Subject: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-07.txt



A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-glue-is-not-optional-07


This version has minor changes in response to Murray Kucherawy's AD
review.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : DNS Glue Requirements in Referral Responses
Authors : M. Andrews
  Shumon Huque
  Paul Wouters
  Duane Wessels
  Filename: draft-ietf-dnsop-glue-is-not-optional-07.txt
  Pages   : 12
  Date: 2022-09-27

Abstract:
   The DNS uses glue records to allow iterative clients to find the
   addresses of name servers that are contained within a delegated zone.
   Authoritative Servers are expected to return all available glue
   records for in-domain name servers in a referral response.  If
   message size constraints prevent the inclusion of all glue records
   for in-domain name servers, the server MUST set the TC flag to inform
   the client that the response is incomplete, and that the client
   SHOULD use another transport to retrieve the full response.  This
   document updates RFC 1034 to clarify correct server behavior.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-glue-is-not-optional-07.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-glue-is-not-optional-07


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] REMINDER: Soliciting presentation proposals for ICANN DNS Symposium 2022

[Matt Larson]

[cid:F6133EC5-9373-4081-B023-74DDCFFBDCD0]

Dear colleagues,

We are still soliciting presentation proposals for the ICANN DNS Symposium (IDS 
2022), which will be held on 15-16 November 2022 in Brussels, Belgium. IDS 2022 
will be co-located with the first ever IANA Community Day on 17 November 2022. 
The call for presentations is open until 14 October 2022. Thank you to everyone 
who has already submitted a presentation proposal.

The theme for IDS 2022 is “Examining the effects of both centralization and 
diversification in the DNS”.

There has been a move toward centralization in the Domain Name System (DNS): 
the devices of more than 20% of Internet users are configured to use public 
resolvers, according to some studies; a small set of registry service providers 
are responsible for a large set of top-level domains; an attack against a 
single service provider’s infrastructure can affect a large percentage of 
Internet users. At the same time, there are more public resolver services and 
more top-level domains than ever. This prompts the question, “Is the DNS overly 
centralized or adequately diversified?” ICANN invites speakers to present 
topics on centralization and diversification in the DNS. Presentations could 
include measurements and fact-based predictions, discussions about risk 
mitigation and scalability in relation to either greater or lesser 
centralization, greater or lesser diversity, or both.

If you are interested to present, please send a one-paragraph description of 
your proposed topic to ids-propos...@icann.org 
by 14 October 2022. We will publish a preliminary agenda by 1 November 2022.

IANA Community Day is a half-day workshop focused on key technical evolution 
projects within IANA relating to the DNS. Topics will include a discussion of 
how to perform a DNSSEC algorithm rollover for the DNS root zone, and reviewing 
and updating the TLD technical requirements for root zone changes. TLD 
managers, DNS experts, and other interested parties are encouraged to attend.

For more information on both IDS and IANA Community Day, including schedule, 
venue and registration information, please visit https://www.icann.org/ids.

Thank you and we hope to see you there!

Matt Larson
VP of Research
ICANN Office of the CTO


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

[Kazunori Fujiwara]

Abley-san, thanks very much for your comments.

> From: Joe Abley 
> Fujiwara-san,
> 
> On Sep 22, 2022, at 11:05, Kazunori Fujiwara  wrote:
> 
>> Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and
>> they often don't work as expected.
>> 
>> However, it may be easy to avoid using the Fragment Header on IPv6.
>> (limit IPv6 response packet smaller than interaface MTU.)
>> (Or, is it not easy ?)
> 
> I think it's easier if we just recommend a maximum message size for UDP 
> transport that is likely to avoid truncation in the majority of cases. 
> Perhaps that is the simplest formulation of your ultimate goal? Just update 
> the base specification and say it clearly. 
> 
> This will make UDP transport only usable for a subset of DNS messages that 
> are ever sent on the Internet. Other transports can remain as-is and do not 
> need this limitation. People who ignore the recommendation are on their own.  

The minimum MTU on IPv6 is 1280.
Then, for example,
we can specify a maximum message size for UDP transport on IPv6 as 1232.

However, the minimum MTU on IPv4 is 68 (Section 3.2 of RFC 791).
We need to arbitarily specify the maximum message size for UDP/IPv4.
For example, 512, 1232, or 1400.

> UDP then becomes a convenient choice for DNS messages that are small and that 
> do not have requirements for confidentiality, bit not a default choice in the 
> protocol sense (despite the fact that it will probably remain the choice for 
> most messages).

> The default transport becomes TCP, since that is the alternative, 
> must-implement transport available in all parts of the system.

We can say that the standard transports for DNS are TCP/DoT/DoQ and
the standard address family is IPv6, however, UDP transport for DNS
and IPv4 will be used in reality, forever.

I believe that the BCP document improves many current use cases.

>> Then, to allow larger than 1232/1400 and smaller than interface MTU
>> response packets, recommendations for UDP requestors are changed as:
>> 
>>  UDP responders can send reponses fit in both
>>  the result of path MTU discovery (if available),
>>  interface MTU and UDP requestor's payload size.
> 
> I think a formulation to avoid magic numbers is probably better but to be 
> honest I don't find magic numbers to be so terrible if they make the advice 
> more clear.
> 
> (I think the current draft's advice is not particularly clear since it 
> contains a lot of
> if then else, but perhaps others think differently.)

>From EDNS spec [RFC6891], response size <= UDP requestor's payload size.

as new recommendations, 
  Set IP_DF bit on IPv4,
  Compose response packet fit in interface MTU -> No Fragment header on IPv6.
  then we don't need the result of path MTU discovery.

> The DNS is used in private networks as well as on the Internet. I think it's 
> ok to say simply that UDP transport is NOT RECOMMENDED for large messages 
> since fragmentation SHOULD be assumed to be unavailable.

I agree. On that case, TC=1 responses will return.

> That leaves wriggle room for implementations who have more knowledge of their 
> network path or who don't care about delivery failures (for example) to do 
> their own thing. I don't think we should spend too much time imagining what 
> those things should be.
> 
 4. TCP implementations SHOULD set DF bit / not use FRAGMENT header.
(many TCP implementations already set DF bit)
>>> 
>>> I doubt we have control over this from the application. Is there even
>>> API to control that on TCP sockets?m
> 
> I don't think we should write as if UDP and TCP are the only transports 
> available. I also think it's a mistake to dive down into rabbit holes 
> relating to any particular transport other than UDP.

I agree. But until draft-ietf-dprive-unilateral-probing will be
published as a RFC, UDP and TCP are only transport to authoritative
servers.

> UDP is the only transport we have in which the DNS protocol needs to care 
> about message size. I think the current draft does a good job in restricting 
> its discussion to UDP.
> 
>> At least, I would like to disable IPv6 fragmentation.
>> and I would like to make "avoid IPv4 fragmetion" our goal.
> 
> I think we should just be bold and declare a RECOMMENDED maximum message size 
> when using UDP transport and make TCP the default choice of transport.

Minimal MTU size for IPv4 is 68.
Then, 512 octet DNS response may be fragmented (without DF bit).

> UDP becomes an acceptable alternative to TCP alongside other transports that 
> might be available, if suitable for a particular message, according to local 
> policy. 
> 
> The maximum that is specified could be a magic number (like the original 
> specification's 512 bytes) or it could be a formulation based on particular 
> address families' minimum capabilities. Clearly some people prefer the 
> latter. 
> 
> The question of how to construct a minimum sized response in cases where a 
> DNS responder really wants to avoid a trip through