Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-extended-error-14
Eric Orth writes: > I have similar objections to this as the similar language that was in the > draft > before it was changed to the "MUST continue to follow" language referenced > above. > > Anything similar to "MUST NOT alter ... processing" is vague over what > constitutes an alteration to the processing. I think everybody would agree > that you should be able to log EDEs, so it must be unambiguous that doing so > is > allowed. Lots of discretionary room for implementers (especially stub > implementers) to do various things with an EDE while still following the specs > on the important handling of the RCODE as the primary error code. > > Hi Eric, Thanks for the (again) well thought out comments. Do you have a counter proposal sentence that could be added to the security seciton? -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-extended-error-14
Eric Orth writes: > I have similar objections to this as the similar language that was in the > draft > before it was changed to the "MUST continue to follow" language referenced > above. > > Anything similar to "MUST NOT alter ... processing" is vague over what > constitutes an alteration to the processing. I think everybody would agree > that you should be able to log EDEs, so it must be unambiguous that doing so > is > allowed. Lots of discretionary room for implementers (especially stub > implementers) to do various things with an EDE while still following the specs > on the important handling of the RCODE as the primary error code. > > Hi Eric, Thanks for the (again) well thought out comments. Do you have a counter proposal sentence? > > -- > Wes Hardaker > USC/ISI > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2020-04-23
The Domain Name System Operations (dnsop) Working Group will hold a virtual interim meeting on 2020-04-23 from 17:00 to 18:00 Europe/Amsterdam (15:00 to 16:00 UTC). Agenda: # DNS Operations (DNSOP) Working Group ## interim-2020-dnsop-02 * Date: 23 April 2020 * Time: * Webex: ### * Jabber: dn...@jabber.ietf.org * EtherPad: ### Chairs * Tim Wicinski tjw.i...@gmail.com * Suzanne Woolf suzworldw...@gmail.com * Benno Overeinder be...@nlnetlabs.nl ### IESG Overlord * Warren Kumari war...@kumari.net ### Document Status * https://github.com/DNSOP/wg-materials/blob/master/dnsop-document-status.md ### Datatracker * https://datatracker.ietf.org/wg/dnsop/documents/ # Agenda ## Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ## Current Working Group Business ### YANG Types for DNS Classes and Resource Record Types - https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ - Ladislav Lhotka, 10 min - Chairs Action: ### Interoperable Domain Name System (DNS) Server Cookies - https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ - Willem Toorop, 15min - Chairs Action: How close to WGLC? # ## New Working Group Business ### DNS TIMEOUT Resource Record - https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/ - Tom Pusateri/Tim Wattenberg, 15 min - Chairs Action: Adopt? ### Delegation Revalidation by DNS Resolvers - https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/ - Shumon Huque, 15 min - Chairs Action: # ## Reference ### BlueSheets Attendees are asked to visit and enter your Name+Affiliation in the Blue-Sheet section of the DNSOP Etherpad. ### Mic Line Queue The Mic Line will use the WebEx chat channel. To get in the queue type q+ to leave type q-. Please don't type questions or other things into the WebEx chat channel as that will make managing the queue very hard for the chairs. Please use the Jabber channel for side conversations. When you connect into WebEx you should start off as auto-muted so you'll need to unmute yourself to speak when called. ### Helpful Info & Prep The IETF has prepared a couple of documents to help get everyone ready. https://www.ietf.org/how/meetings/107/session-participant-guide/ https://www.ietf.org/how/meetings/107/session-presenter-guide/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m8d49e59807a47eec1d8cf5fbd4f81fa3 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Doodle poll for DNSOP WG interim 23 April 2020
The DNSOP WG interim meeting on April 23 is scheduled for 15:00-16:00 UTC. Details about agenda, webex, etherpad will soon be posted to the mailing list. Best regards, -- Benno On 16/04/2020 10:18, Benno Overeinder wrote: > Gentle reminder. Poll closes today. > > https://doodle.com/poll/zk9f4ur7fycz3kra > > Thank you, > > Suzanne, Tim and Benno > > > On 14/04/2020 18:26, Benno Overeinder wrote: >> Dear DNSOP WG, >> >> Thank you for your time and participation in the DNSOP WG meeting today. >> >> The next DNSOP WG interim meeting is scheduled for April 23 and will be >> a one hour virtual meeting. To select a timeslot, we again created a >> doodle poll: >> >> https://doodle.com/poll/zk9f4ur7fycz3kra >> >> Please fill in the doodle before the end of Thursday (April 16). >> >> >> Thank you, >> >> Suzanne, Tim and Benno >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] dnsop - New Interim Meeting Request
A new interim meeting request has just been submitted by Benno Overeinder. This request requires approval by the Area Director of the Operations and Management Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-dnsop-02 - Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Benno Overeinder Meeting Type: Virtual Meeting Session 1: Date: 2020-04-23 Start Time: 17:00 Europe/Amsterdam Duration: 01:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m8d49e59807a47eec1d8cf5fbd4f81fa3 Agenda Note: - ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02
Hello, First off, I have started implementing support for SVCB and HTTPSSVC as part of the dnspython library [0] and I'd be interested in doing some interop testing with other people's implementations. I also have a few comments/questions about the draft, apologies if they have already been discussed in the past (haven't been following the draft from the start). 1. For interop testing purposes it would be very helpful if the draft listed commonly agreed upon code-points for the new RR types. Ideally in the form of an official early assignment from IANA, but if that's not possible picking a couple of codepoints at random from the "private use" range would also be helpful. In my implementation I'm currently using "65481" for SVCB and "65482" for HTTPSSVC. 2. The structure of the draft is a bit odd, as it lists a bunch of examples before introducing any of the records. This was a bit confusing to me, so I'd suggest moving sections 1.5 and 1.6 _before_ the examples (that is, immediately after the introduction). It might also be a good idea to just move the examples to an Appendix instead. 3. Would it make sense to move the ESNI/ECHO config paramenter to the ESNI/ECHO draft instead? This way the DNS draft wouldn't need to depend on the ESNI draft (so e.g. if ESNI ends up taking longer, this draft could be published without having to wait for it). 4. What is the point of differentiating between AliasForm and ServiceForm? Like, couldn't the draft just say that the SvcFieldValue is an optional field and be done with that? It seems like not having to explicitly differentiate the two cases would simplify the draft a bit without sacrificing much, though I might be missing something. 5. Section 2.1.1 says The presentation format for SvcFieldValue is a whitespace-separated list of elements representing a key-value pair, with an absent value or "=" indicating an empty value. It took me longer than I'd like to admit to understand the "with an absent value or "=" indicating an empty value" part. I'd suggest rewording that paragraph to something like: The presentation format for SvcFieldValue is a whitespace-separated list of key=value pairs (e.g. "key123=value1 keys456=value2"). When the value, or both the value and the "=" are omitted, the value should be interpreted as being empty. Or something better :) 6. In Section 2.2 it says (in reference to param field values): o an octet string of the length defined by the previous field. It might be good to say here that the format of this octet string is defined according to the corresponding SvcParamKey, and then reference section 6 for ths currently defined keys. The same applies for section 2.1.1 for the presentation format. 7. Section 4.3 says: All DNS servers SHOULD treat the SvcParam portion of the SVCB RR... Should it be SvcFieldValue instead of SvcParam? "SvcParam" is not mentioned anywhere else. 8. Maybe I'm missing something, but the following sentence in Section 6.4 seems wrong: When SvcDomainName is ".", server operators SHOULD NOT include these hints, because they are unlikely to convey any performance benefit. My understanding is that ipv4hint and ipv6hint are the way to solve the ESNI multi-CDN problem, so let's say I have "www.example.net" that CNAMEs to both "cname.cdn-a.example" and "cname.cdn-b.example". A client queries both A and HTTPSVC concurrently for "www.example.net", and receives two answers (the answer to the A query points to CDN A, while the answer to HTTPSSVC points to CDN B): www.xample.net 3600 IN CNAME cname.cdn-a.example cname.cdn-a.example 3600 IN A 192.0.2.1 and www.xample.net 3600 IN CNAME cname.cdn-b.example cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=h3 esniconfig="..." My understanding is that in this case the client could end up connecting to 192.0.2.1 (CDN A) with CDN B's ESNI config (or e.g. with the wrong ALPN). So if the server doesn't provide IP hints there would indeed be impact on performance because the client would just straight up fail to connect initially (e.g. maybe CDN A doesn't support HTTP/3, but CDN B's HTTPSSVC says the client can use it, or just because of the wrong ESNI config). Long story short, I don't think the text should discourage setting ipv4hint and ipv6hint here. I get that it's SHOULD NOT and not MUST NOT, but it's pretty confusing nevertheless. 9. Speaking of multi-CDN, AFAICT the problem is mentioned only once in the whole draft and only in relation to ESNI. However this is not ESNI-specific and also affects e.g. HTTP/3 as per the example above. So I think it would be useful to go into a little more detail on this. 10. Section B.2: s/pther/other/ Cheers [0] https://github.com/rthalley/dnspython/pull/452 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On Powerbind
On Fri, 17 Apr 2020 at 10:27, Olaf Kolkman wrote: > Looking for this: > https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml ? > I guess we were. The extraneous bits appear to be remnants of DNSKEY's previous life as a KEY RR, defined in RFC2535 3.1.2, and presumably now obsolete. Thanks Olaf. --Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On Powerbind
Looking for this:
https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml ?
—Olaf
PS. Haven’t looked at this code for over a decade. That last croak,
Postel principle violation?
On 16 Apr 2020, at 23:08, Dick Franks wrote:
Warren,
Comments in line
On Thu, 16 Apr 2020 at 20:31, Warren Kumari wrote:
8
Just checking - the DNSKEY Flags field is 16 bits, and we have so far
burned:
Bit 15 - SEP
Bit 7 - Zone key
Bit 8 - Revoked
Did I miss any (I wasn't able to find a registry for this)?
If not, we still have 13 bits left, and so using one for this seems
ok
to me, especially if recursives doing something with it is
optional...
(I had mistakenly remembered the Flags as being only 8 bits)
I'm still not convinced that DNSSEC Transparency will come to pass,
nor that many zones will use this flag, but I'm now much more
sanguine
about giving it a bit...
The lack(?) of a registry is indeed regrettable.
However, there seems to be some historical meaning attached to some of
the other flag bits.
If I look back at Net::DNS::SEC 0.17, bequeathed to me by one Olaf
Kolkman, the DS create() method contains the following mysterious
(perl) lines, for which I can offer no coherent explanation:
# The key must not be a NULL key.
if (($keyrr->{"flags"} & hex("0xc000") ) == hex("0xc000") ){
croak "\nCreating a DS record for a NULL key is illegal";
}
# Bit 0 must not be set.
if (($keyrr->{"flags"}) & hex("0x8000")) {
croak "\nCreating a DS record for a key with flag bit 0 set ".
"to 0 is illegal";
}
# Bit 6 must be set to 0 bit 7 must be set to 1
if ( ($keyrr->{"flags"} & hex("0x300")) != hex("0x100")){
croak "\nCreating a DS record for a key with flags 6 and 7 not
set ".
"0 and 1 respectively is illegal";
}
which would seem to indicate that some of the other bits were thought
to have some meaning circa 2013.
Perhaps Olaf can shed some light on this topic.
Dick Franks
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Olaf M. Kolkman Tweets as: @kolkman
Principal - Internet Technology, Policy, and Advocacy
Internet Societyhttps://www.internetsociety.org
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
