[DNSOP] Minutes from interim-2021-dnsop-01

[Tim Wicinski]

All

Thanks to those who attended the Interim, and thanks Paul for putting these
together for us.   Here are the draft minutes:

https://datatracker.ietf.org/doc/minutes-interim-2021-dnsop-01-202109150100/

As usual, if you spot something which you feel needs correcting, let us
know.

The chairs are going to sit down with the authors and come up with
questions we'll ask the working group for consensus.

thanks
tim
DNS Operations (DNSOP) Working Group
Interim-2021-dnsop-01
Chairs: Tim Wicinski, Suzanne Woolf, Benno Overeinder
Minutes taken by Paul Hoffman
Text from slides not included


draft-ietf-dnsop-avoid-fragmentation
https://datatracker.ietf.org/doc/slides-interim-2021-dnsop-01-sessa-dnsop-avoid-fragmentation/
Kazunori Fujiwara
Brian Dickson: Maybe look at differences between stub-to-recursive and 
recursive-to-auth
Paul Hoffman: Maybe have this be an informational document because it is 
not a single practice
Warren Kumari: Informational is OK
Brian: Could be a BCP if we have a must-not-exceed value
Being a BCP will have people realize "this is really important"
Peter Koch: Could live with a single value for developers, but need 
configurations for operators
BCP could be "apply these considerations for good reasons"
Tim: Would need logic for each choice
Warren: It makes more sense to ask for a BCP, but let it be downgraded to 
informational by the IESG
Mark Andrews: Has an expired draft about well-known TSIG
Will defeat all fragmentation attacks, rather than saying "do not 
fragment on UDP"
Current proposal leads to black holes in routers
Can do what we want at the DNS layer instead of the IP layer
Wants the WG to look at his proposal

https://www.ietf.org/archive/id/draft-andrews-dnsop-defeat-frag-attack-00.txt
Don't switch to TCP too early
Brian: Thinks 1452 is a resonable number
Likely to get through even the biggest tunnels
What should auth servers set its buffer size?
PaulH: The author's preferred value needs to be justified, not just stated
Suzanne Woolf: Might be looking at this backwards
The BCP is "don't just blindly pick a number, choose your use case and 
compare them to what's listed"
Tim: Maybe breaking out the roles to make more obvious

draft-ietf-dnsop-glue-is-not-optional
https://datatracker.ietf.org/doc/slides-interim-2021-dnsop-01-sessa-glue-is-not-optional/
Duane Wessels
Brian: Intent should be if you don't include sibling glue, must set TC=1
Must include it if over TCP
Wants a MUST with refined wording
Make it more clear
Ben Schwartz: Would prefer zone operators must not construct sibling glue 
loops
Authoritative servers can ignore zones with loops
This is not a performance optimization
Mark: This is not meant as an optimization, it is to make sure the 
resolver can make the next query
You might succeed, but if there is a loop there, the resolution 
will fail
Ben: Make it fail
Paul: Would need to change the wording for RFC 1034 if we go to SHOULD
John Levine: Clarify the new sentence for 1034
Agrees with Ben on MUST NOT for sibling loops
Worth adding more words
Duane: Please send text
Warren: There should be an example of a sibling glue loop
"Don't do this"
Brian: Sympathetic to the concept of getting rid of sibling glue loops
Could be arbitrarily deep in the DNS tree
Not feasible to look too far down
Ben: Don't create a loop, but auth servers MAY configure not to serve 
them
The behavior has to be compatible
Paul: Restated the need to change the 1034 wording if we differentiate 
sibling glue from classic glue
Ben: Doesn't feel that the portability of zones with sibling glue loops is 
a priority
Brian: Interoperability, not portability
Depends where the sibling glue lives, particularly down the tree
Duane: Hearing both opinions
Most current authoritative implementations fit as much glue as they 
can, don't truncate
This draft changes the "some but not all fit" situation
Things will continue to work, but will see more TCP traffic
Suzanne: Maybe corner cases
Need to resolver these issues, but primary message needs to be clear
Brian: Third case: if the auth server is configured to be narrow glue 
policy, that's different than today
Should be permissable, TC=1 must be set
Ben: Two questions: what is the glue policy, and what happens when the glue 
doesn't fit
Separate out the glue policy
Permit a range of behaviors
Brian: Behavior over TCP is not affecteb by the glue policy
Tim: need more from the mailing list

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

Re: [DNSOP] REMINDER: DNSOP Interim 2021-09-15 01:00 - 02:00 UTC

[Benno Overeinder]

Hi all,

The Meetecho URL for the interim meeting is:
https://meetings.conf.meetecho.com/interim/?short=a910f22a-d46b-401f-be04-97c290437214

All material (agenda, slides, etc.) for the interim meeting can be found 
here:

https://datatracker.ietf.org/meeting/interim-2021-dnsop-01/session/dnsop

Best,

-- Benno

On 14/09/2021 02:31, Tim Wicinski wrote:

All

A Reminder that there is an upcoming DNSOP Interim meeting.
This will be happening at 2021-09-15 01:00 - 02:00 UTC.
Please adjust for your local time zone.

The Meetecho URL is:
https://meetings.conf.meetecho.com/interim/?short=a910f22a-d46b-401f-be04-97c290437 
214


Two items for discussion:

* dnsop-avoid-fragmentation
* dnsop-glue-is-not-optional

Thanks, and hopefully folks can make it.

tim



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