Re: [DNSOP] HTTPS SVCB no service available signal.

2020-07-09 Thread Mark Andrews
> On 10 Jul 2020, at 11:53, Joe Abley wrote: > > On 9 Jul 2020, at 18:48, Mark Andrews wrote: > >> On 10 Jul 2020, at 08:17, Joe Abley wrote: >> >>> On Jul 9, 2020, at 17:18, Ben Schwartz >>> wrote: >>> This seems like a reasonable idea to me. We should be able to incorporate

Re: [DNSOP] draft-ietf-dnsop-respsize, was partial glue

2020-07-09 Thread John Levine
In article <1738263.TRGBkWWA7Y@linux-9daj> you write: >by the way, this is what kato and i, and later jabley, were trying to get at >with > >https://datatracker.ietf.org/doc/draft-ietf-dnsop-respsize/ > >but it was like moving mud with a toothpick, so after eleven years (2003 to >2014) we gave

Re: [DNSOP] HTTPS and SVBC key names.

2020-07-09 Thread Erik Nygren
Or 64? - Erik [Sent from my IPv6 connected T-Mobile 4G LTE mobile device] On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz wrote: > How about 255 characters? > > On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews wrote: > >> Can we please have a length limit on key names? At the moment they could

Re: [DNSOP] HTTPS SVCB no service available signal.

2020-07-09 Thread Brian Dickson
On Thu, Jul 9, 2020 at 3:49 PM Mark Andrews wrote: > > > > On 10 Jul 2020, at 08:17, Joe Abley wrote: > > > > On Jul 9, 2020, at 17:18, Ben Schwartz 40google@dmarc.ietf.org> wrote: > > > >> This seems like a reasonable idea to me. We should be able to > incorporate this for the next draft

Re: [DNSOP] HTTPS SVCB no service available signal.

2020-07-09 Thread Joe Abley
On 9 Jul 2020, at 18:48, Mark Andrews wrote: > On 10 Jul 2020, at 08:17, Joe Abley wrote: > >> On Jul 9, 2020, at 17:18, Ben Schwartz >> wrote: >> >>> This seems like a reasonable idea to me. We should be able to incorporate >>> this for the next draft revision. >> >> I guess I'll

Re: [DNSOP] HTTPS and SVBC client support measurement.

2020-07-09 Thread Tommy Pauly
> On Jul 9, 2020, at 5:27 PM, Ben Schwartz > wrote: > > > > On Thu, Jul 9, 2020, 8:04 PM Mark Andrews > wrote: > It would be useful if there was a way to measure client support for HTTPS and > SVBC even when they are not in use. Perhaps a HTTP header could be added

[DNSOP] HTTPS and SVBC key names.

2020-07-09 Thread Mark Andrews
Can we please have a length limit on key names? At the moment they could be a billion characters long as they don’t go over the wire. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: [DNSOP] HTTPS and SVBC client support measurement.

2020-07-09 Thread Mark Andrews
> On 10 Jul 2020, at 10:27, Ben Schwartz wrote: > > > > On Thu, Jul 9, 2020, 8:04 PM Mark Andrews wrote: > It would be useful if there was a way to measure client support for HTTPS and > SVBC even when they are not in use. Perhaps a HTTP header could be added to > signal that the client

[DNSOP] HTTPS and SVBC client support measurement.

2020-07-09 Thread Mark Andrews
It would be useful if there was a way to measure client support for HTTPS and SVBC even when they are not in use. Perhaps a HTTP header could be added to signal that the client supports HTTPS? This will provide server administrators information about their client population to decide when it

Re: [DNSOP] HTTPS SVCB no service available signal.

2020-07-09 Thread Mark Andrews
> On 10 Jul 2020, at 08:17, Joe Abley wrote: > > On Jul 9, 2020, at 17:18, Ben Schwartz > wrote: > >> This seems like a reasonable idea to me. We should be able to incorporate >> this for the next draft revision. > > I guess I'll mention that when I suggested MNAME=. to indicate that a

Re: [DNSOP] HTTPS SVCB no service available signal.

2020-07-09 Thread Tommy Pauly
+1 When implementing the client, this case needs to be caught anyhow (the error of aliasing to your own domain), so it has the effect of indicating that no service is valid. This suggestion turns this case from an error (which still had the desired effect), to a proper signal. Tommy > On Jul

Re: [DNSOP] HTTPS SVCB no service available signal.

2020-07-09 Thread Joe Abley
On Jul 9, 2020, at 17:18, Ben Schwartz wrote: This seems like a reasonable idea to me. We should be able to incorporate this for the next draft revision. I guess I'll mention that when I suggested MNAME=. to indicate that a zone did not accept dynamic updates, the proposal was roundly shot

[DNSOP] HTTPS SVCB no service available signal.

2020-07-09 Thread Mark Andrews
We should use “HTTPS 0 .” to signal that there is no service offered. Similarly for SVCB. Currently “.” has no useful purpose in the alias form. -- Mark Andrews ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt

2020-07-09 Thread Marek Majkowski
On Thu, Jul 9, 2020 at 10:28 AM wrote: > > From: Marek Majkowski > >> UDP requestors and responders SHOULD send DNS responses with > >> IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] options, which will yield > >> either a silent timeout, or a network (ICMP) error, if the path > >> MTU is exceeded. > > >

Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt

2020-07-09 Thread Marek Majkowski
On Thu, Jul 9, 2020 at 3:35 AM Mark Andrews wrote: > > I have two problems with this proposal. First, it doesn't mention IPv4 > > vs IPv6 differences at all. In IPv4 landscape fragmentation, while a > > security issue, is generally fine. In the IPv6 world, fragmentation is > > disastrous -

Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt

2020-07-09 Thread fujiwara
> From: Marek Majkowski >> UDP requestors and responders SHOULD send DNS responses with >> IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] options, which will yield >> either a silent timeout, or a network (ICMP) error, if the path >> MTU is exceeded. > > When MTU is exceeded the sender might also receive

Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt

2020-07-09 Thread tirumal reddy
On Thu, 9 Jul 2020 at 12:52, Vittorio Bertola < vittorio.bert...@open-xchange.com> wrote: > > Il 09/07/2020 08:53 tirumal reddy ha scritto: > > Regarding section 4, in DPRIVE (on draft bcp-op) we have recently been > told that the IETF does not recommend in its best practices anything which > is

Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt

2020-07-09 Thread Vittorio Bertola
> Il 09/07/2020 08:53 tirumal reddy ha scritto: > > > > > Regarding section 4, in DPRIVE (on draft bcp-op) we have > recently been told that the IETF does not recommend in its best practices > anything which is not strictly technical (in that case, it was about >

Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt

2020-07-09 Thread tirumal reddy
On Wed, 8 Jul 2020 at 18:51, Bob Harold wrote: > > On Wed, Jul 8, 2020 at 3:38 AM tirumal reddy wrote: > >> Hi all, >> >> This draft https://tools.ietf.org/html/draft-reddy-dnsop-error-page-00 >> discusses a method to return an URL that explains the reason the DNS query >> was filtered. It is

Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt

2020-07-09 Thread tirumal reddy
On Wed, 8 Jul 2020 at 18:28, Vittorio Bertola < vittorio.bert...@open-xchange.com> wrote: > > Il 08/07/2020 09:37 tirumal reddy ha scritto: > > > Hi all, > > This draft https://tools.ietf.org/html/draft-reddy-dnsop-error-page-00 > discusses a method to return an URL that explains the reason the