t is difficult to tell without
getting feedback, so please let me know what you think.
Brian Dickson
-- Forwarded message -
From:
Date: Fri, Sep 17, 2021 at 1:20 PM
Subject: New Version Notification for draft-dickson-dnsop-glueless-01.txt
To: Brian Dickson
A new version of I-D, d
e subject of a draft I will be posting in DPRIVE, for
those interested.)
I think it's fairly straightforward, but it is difficult to tell without
getting feedback, so please let me know what you think.
Brian Dickson
-- Forwarded message -
From:
Date: Fri, Sep 17, 2021 at 1:2
ults and behavior may have varied, but were definitely not universal
success.
I'm not sure if some implementation combinations might have "worked", but
certainly not the majority of combinations.
Brian
On 8/12/21 3:15 AM, Brian Dickson wrote:
> This is the work I will be submittin
> Stats are probably available showing how often queries are made for DNS
>> operator's zones that indicate a cold cache is being used. Absent a
>> compelling case for the cold cache, it does not seem to be worth any effort.
>>
>
> Perhaps we can find some stats, but I think the "cold cache" case i
Apologies to anyone following this thread... these messages are getting
very large, necessarily.
(Paul H, you may want to skip down to an example I provided, look for
ORIGIN text.)
On Mon, Aug 16, 2021 at 9:15 PM Ben Schwartz wrote:
>
>
> On Mon, Aug 16, 2021 at 7:40 PM Bria
On Mon, Aug 16, 2021 at 3:14 PM Ben Schwartz wrote:
>
>
> On Mon, Aug 16, 2021 at 2:05 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
> ...
>
>> I'm arguing against the parent ever putting SVCB records in any
>> delegation response, reg
On Mon, Aug 16, 2021 at 11:16 AM Ben Schwartz wrote:
>
>
> On Sat, Aug 14, 2021 at 7:37 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Sat, Aug 14, 2021 at 3:47 PM Paul Hoffman
>> wrote:
>>
> ...
>
>> For
On Sat, Aug 14, 2021 at 3:47 PM Paul Hoffman wrote:
> On Aug 13, 2021, at 8:40 AM, Ben Schwartz 40google@dmarc.ietf.org> wrote:
> > I think we can summarize the recent DS-glue-signing drafts as follows:
> >
> > * draft-fujiwara-dnsop-delegation-information-signer: One new DS holding
> a hash
Hi, Joe,
Please allow me to interject, on a few different issues from this thread…
Sent from my iPhone
> On Aug 12, 2021, at 4:39 PM, Joe Abley wrote:
>
> Hi Paul,
>
>> On 12 Aug 2021, at 15:48, Paul Wouters wrote:
>>
>> On Thu, 12 Aug 2021, Joe Abley wrote:
>>
This would have been ex
Sent from my iPhone
> On Aug 12, 2021, at 12:21 PM, John Levine wrote:
>
> It appears that Brian Dickson said:
>> -=-=-=-=-=-
>>
>> This is the work I will be submitting in DNSOP.
>>
>> This is what has been described as a “hack”, but pr
This is the work I will be submitting in DNSOP.
This is what has been described as a “hack”, but provides a needed validation
link for authoritative servers where the latter are in signed zones, but where
the served zones may not be signed.
NB: It overlaps with the recent DPRIVE draft that Ben
On Tue, Aug 10, 2021 at 3:48 PM Shumon Huque wrote:
> On Tue, Aug 10, 2021 at 1:55 PM Paul Hoffman
> wrote:
>
>> Greetings again. In the DPRIVE WG, we are discussing a proposal that
>> would make encrypting transport on a first lookup more likely using a DS
>> hack. Whether or not that becomes a
On Tue, Jul 27, 2021 at 4:35 PM Shumon Huque wrote:
> Folks,
>
> While we have the attention of DNSOP folks this week, I'd like to ask for
> review of this draft (I meant to send it earlier in time for f2f discussion
> on Tuesday, but better late than never).
>
>
> https://datatracker.ietf.org/do
On Tue, Jul 27, 2021 at 1:29 PM Joe Abley wrote:
> On 27 Jul 2021, at 16:15, John Levine wrote:
>
> >> * Section 5: Promoted or orphan glue
> >> The considerations for handling orphan glue will be different for a
> >> TLD vs a lower level zone within a domain. I would think that orphan
> >> glue
On Tue, Jul 13, 2021 at 10:01 AM Viktor Dukhovni
wrote:
> > On 13 Jul 2021, at 6:22 am, Petr Špaček wrote:
> >
> > As Viktor pointed out in
> https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs/
> , it seems that this problem plagues roughly tens out of 150k domains he
> surv
On Mon, Jul 12, 2021 at 2:20 AM Petr Špaček wrote:
> On 08. 07. 21 18:15, Brian Dickson wrote:
> >
> >
> > On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček > <mailto:pspa...@isc.org>> wrote:
> >
> > On 07. 07. 21 19:54, Warren Kumari wrote:
> >
ot; it.
Did you actually read what Viktor wrote?
It is a known fact that there ARE implementations where ENT handling (on
the authoritative side) are broken.
Given that the vast majority of the first underscore queries would be
hitting ENTs, this would seem to me, at least, to be compelling.
Why
On Wed, Jul 7, 2021 at 10:55 AM Warren Kumari wrote:
> Hi there all,
>
> I wanted to check the consensus on a point brought up during IETF LC /
> OpsDir review of draft-ietf-dnsop-rfc7816bis.
>
> Please see:
>
> https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/
> and
>
On Tue, Jun 15, 2021 at 12:03 PM Paul Wouters wrote:
> On Tue, 15 Jun 2021, Shumon Huque wrote:
>
> > On Tue, Jun 15, 2021 at 12:46 PM Tim Wicinski
> wrote:
> >
> > Yes, Stephane, we were envisioning recommending an
> underscore label. Of course, that leads to how to avoid collisions
On Fri, Jun 18, 2021 at 12:06 PM Joe Abley wrote:
> On 18 Jun 2021, at 14:45, Paul Wouters wrote:
>
> > On Jun 18, 2021, at 13:41, Peter van Dijk
> wrote:
> >
> >> I propose replacing rfc5011-security-considerations with a short
> document deprecating 5011 in its entirety.
> >
> > Eh? 5011 is
I think there is a need for something similar to RFC3597, except for fields
in a record rather than a BLOB for the record itself.
RFC3597 is fine for an RRTYPE with only one RDATA element/structure, but
not for complex RRs.
Context: there is a general problem on sub-field encodings (i.e. which has
On Thu, May 20, 2021 at 11:29 AM Ralf Weber wrote:
> Moin!
>
> On 20 May 2021, at 19:59, Eric Orth wrote:
>
> > A big selling point behind why we have client implementers planning to
> > query HTTPS records is the expectation that this will be the only query
> > type we will need to add and that
On Wed, May 19, 2021 at 7:15 PM Mark Andrews wrote:
>
>
> > On 20 May 2021, at 11:52, Paul Wouters wrote:
> >
> > On Wed, 19 May 2021, Ben Schwartz wrote:
> >
> >> So long as there are no registered protocol identifiers containing ","
> or "\\", zone file implementations MAY
> >> disallow these
On Wed, May 19, 2021 at 5:52 PM Martin Thomson wrote:
> On Thu, May 20, 2021, at 10:35, Brian Dickson wrote:
> > I was under the impression that the extensibility is for the SVCB type,
> > and not strictly needed for HTTPS.
>
> It is absolutely needed for HTTPS.
>
I&
On Wed, May 19, 2021 at 6:15 PM Martin Thomson wrote:
> On Thu, May 20, 2021, at 11:08, Paul Wouters wrote:
> > This discussion should be around reasonable and secure wire and
> > presentation formats, not about "but we already deployed this".
> > It should surely be taken into account if changin
On Wed, May 19, 2021 at 5:15 PM Erik Nygren wrote:
>
>
> On Wed, May 19, 2021 at 7:01 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, May 19, 2021 at 3:00 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
On Wed, May 19, 2021 at 3:00 PM Brian Dickson
wrote:
>
>
> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman
> wrote:
>
>> Are these still just idle ideas you are tossing out (as you indicated
>> earlier), or meant to be serious proposals? If the latter, what is the
>
On Wed, May 19, 2021 at 2:50 PM Paul Hoffman wrote:
> Are these still just idle ideas you are tossing out (as you indicated
> earlier), or meant to be serious proposals? If the latter, what is the
> significant improvement over the current draft? I ask because it feels like
> you are suggesting m
he zone file
format for HTTPS.
I don't really have major problems with SVCB, as the use case I'm primarily
concerned with is HTTPS.
Also, vendor/operator support for HTTPS and SVCB should also be decoupled.
It should be anticipated that some vendors will support HTTPS but not
support SVCB
On Wed, May 19, 2021 at 7:49 AM Tommy Pauly wrote:
> I wanted to chime in on this discussion as a client-side implementor who
> has already widely deployed support for SVCB/HTTPS.
>
> The current format, where the parameters are structured as a list within a
> single RR, is certainly simpler and
On Tue, May 18, 2021 at 2:35 PM Paul Wouters wrote:
> On Tue, 18 May 2021, Ben Schwartz wrote:
>
> > That's essentially correct. A client that only supports the default
> ALPN has no use for the "alpn" SvcParam.
>
> Does the "default ALPN" mean "no support for the ALPN extension" ? Or
> does it
On Mon, May 17, 2021 at 3:48 PM Ben Schwartz wrote:
> On Mon, May 17, 2021 at 2:46 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>> I re-read (several times) the current -05 version of the draft. I found
>> it difficult to follow and unders
the client, UNLESS the
"optional" flag is present in the HTTPS referenced record
- This rule applies to "ecn", "ip4hint", and "ip6hint" records (each has
its own "optional" flag, and that flag is only applicable to the parameter
associated
On Sat, May 15, 2021 at 8:00 AM Erik Nygren wrote:
> On Wed, May 12, 2021 at 4:44 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>> Having multiple AliasMode records within an RRset (with either the same
>> or different Priority) would p
On Thu, May 13, 2021 at 10:25 AM Ben Schwartz wrote:
>
>
> On Thu, May 13, 2021 at 12:51 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, May 12, 2021 at 9:33 PM Ben Schwartz wrote:
>>
>>> On Wed, May 12
On Fri, May 14, 2021 at 5:47 PM John Levine wrote:
> It appears that Brian Dickson said:
> >I said you weren't going to like it.
>
> No disagreement there.
>
> >I think it should be taken as a safe assumption, that for the vast
> majority
> >of end users,
On Thu, May 13, 2021 at 10:50 AM Ben Schwartz wrote:
>
>
> On Thu, May 13, 2021 at 3:56 AM libor.peltan wrote:
>
>> Hi all,
>>
>> just my comment:
>>
>> Perhaps complexity is subjective. The important thing is that the
>> standard be reasonably implementable. I hope that the list of published
On Wed, May 12, 2021 at 9:33 PM Ben Schwartz wrote:
> On Wed, May 12, 2021 at 7:14 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>> It is demonstrably more likely that a complex parser will have problems,
>> than something that combines data from simpl
On Wed, May 12, 2021 at 3:32 PM Eric Orth wrote:
>
>
> On Wed, May 12, 2021 at 6:21 PM John Levine wrote:
>
>> It appears that Joe Abley said:
>> >> Agreed that there is no such issue with either wire format if all
>> parties in the ecosystem are bug-free and RFC-compliant.
>> >
>> >Do you kno
On Wed, May 12, 2021 at 12:28 PM Eric Orth wrote:
>
> I also oppose allowing multiple aliases within an RRSet. This would allow
> aliasing trees, unreasonably exploding the complexity/performance scope of
> query followup logic in stubs and recursives. In practice, I don't think
> this would ac
On Wed, May 12, 2021 at 12:28 PM Eric Orth wrote:
> I have no strong opinions on any of the discussions regarding escaping in
> presentation mode because I don't have much involvement in dealing with
> presentation mode of DNS records. The client I work with parses wire
> format directly into it
On Tue, May 11, 2021 at 4:16 PM Ben Schwartz wrote:
>
>
> On Tue, May 11, 2021 at 4:13 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
> ...
>
>> What is the difference between
>>
>> foo.example.com HTTPS 0 foo.example.net
>>
>
On Tue, May 11, 2021 at 4:00 PM Ben Schwartz wrote:
>
>
> On Tue, May 11, 2021 at 3:44 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Tue, May 11, 2021 at 2:49 PM Ben Schwartz wrote:
>>
>>>
>>>
>>&
On Tue, May 11, 2021 at 2:49 PM Ben Schwartz wrote:
>
>
> On Tue, May 11, 2021 at 2:31 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
> ...
>
>> Another way to put it is, the SvcParameters are actually bound to the
>> TargetName, not the owner n
On Tue, May 11, 2021 at 11:12 AM Ben Schwartz wrote:
>
>
> On Tue, May 11, 2021 at 10:32 AM Joe Abley wrote:
>
>> On 11 May 2021, at 12:32, Ben Schwartz wrote:
>>
>> > On Tue, May 11, 2021 at 9:20 AM Joe Abley wrote:
>> >> On 11 May 2021, at 12:08, Ben Schwartz > 40google@dmarc.ietf.org> w
On Mon, May 10, 2021 at 9:58 AM Ben Schwartz wrote:
> I don't support breaking the SvcParams into separate RRs across the
> RRSet. This would be an extremely inefficient encoding in wire format, and
> would conflict with the usual understanding of resource records as
> independently meaningful a
On Mon, May 10, 2021 at 12:07 PM Peter van Dijk
wrote:
> On Mon, 2021-05-10 at 10:55 +0200, Benno Overeinder wrote:
> > The draft is available here:
> > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/.
> >
> > Please review this draft to see if you think it is suitable for a
On Fri, May 7, 2021 at 10:03 AM Joe Abley wrote:
> Hi Hugo,
>
> On 7 May 2021, at 12:47, Hugo Salgado wrote:
>
> > I'll upload a new version to revive it, and ask for a slot
> > in IETF111 for further discussion!
>
> Just to add my voice to the chorus, I missed this the first time around so
> th
On Sun, Apr 18, 2021 at 4:17 PM Suzanne Woolf
wrote:
> Dear colleagues,
>
>
> This message starts the Working Group Last Call
> for draft-ietf-dnsop-tcp-requirements (
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/)
>
> Since this draft has not been recently discussed i
I'm not 100% sure off hand
if the current specifications are compatible with my statements. If they
aren't, IMHO they should be either revised or made more clear so as to
support use cases like this.)
Brian Dickson
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Tue, Apr 6, 2021 at 11:11 AM Murray S. Kucherawy
wrote:
> I'm wondering something about tree walks, which John Levine asked about in
> November, as it's a topic of interest to the evolution of DMARC.
>
> I've read RFC 8020 which says an NXDOMAIN cached for "foo.example" also
> covers later que
ware developpers of validating stub resolvers are limited.
> They know DNS protocol well and limit default DNS/UDP payload size
> 1232 or other smaller value.
>
> When full-service resolvers support this draft,
> changing stub resolvers are not necessary, I think.
>
> --
>
ad might cause confusion and errors.)
The resolver would set the DF bit, and if the response is not received, the
client would need to react accordingly. E.g retry, reduce size, iterate
until a response is received.
Feedback on this idea is welcome.
Thanks,
Brian Dickson
__
this suggestion is welcome.
Sincerely,
Brian Dickson
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
d".
The
>server's maximum DNS/UDP payload size SHOULD be smaller than or equal
>to the reported path MTU minus IPv4/IPv6 header size (20/40) minus
>UDP header size (8).
>
>
Sincerely,
Brian Dickson
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Wed, Mar 17, 2021 at 2:05 PM Petr Špaček wrote:
> On 12. 03. 21 4:47, Brian Dickson wrote:
> > On Fri, Oct 30, 2020 at 10:03 AM Roy Arends > <mailto:r...@dnss.ec>> wrote:
> >
> > Dear DNS Operations folk,
> >
> > Matt Larson and I wrot
On Fri, Feb 19, 2021 at 10:58 AM Wes Hardaker wrote:
>
> Greetings all,
>
> Viktor and I have been working on a BCP to provide guidance on selecting
> reasonable NSEC3 parameters. We'd love your feedback and for dnsop to
> consider adopting it.
>
>
> A new version of I-D, draft-hardaker-dnsop-ns
On Fri, Oct 30, 2020 at 10:03 AM Roy Arends wrote:
> Dear DNS Operations folk,
>
> Matt Larson and I wrote up a method that warns a domain owner of an issue
> with their configuration. The idea is loosely based on DMARC (RFC7489), and
> on Trust Anchor signalling (RFC8145).
>
> The method involve
>From the status updates today, I see this draft has expired. I really like
it (and it is quite simple), and would like to see it picked up and
completed (adopted, rough consensus reached, published).
Having reread it and the discussion, I am wondering if useful guidance can
be provided regarding
Sorry for not thinking of these earlier, not sure if they would add
anything or clarify anything or potentially protect resolvers from DOS
attacks:
- Maybe some text warning about queries with excessive numbers of
labels, and suggestions for limiting their impact? E.g. "If NUM_LABELS is
m
I have a very minor comment on this (excellent) draft:
Assuming it gets approved and published, could the relevant elements also
be filed as "Errata" on the respective RFCs, so they are easy to find and
apply?
Not sure if that is appropriate, but given the implications of not doing
what this draft
ion of the zone would need to be served with both sets of
signatures (that's going to be challenging)
Only then can the old DS record be removed, at which point the Algorithm 8
validator will consider the zone to be insecure, without going bogus.
Ick.
Brian
On Tue, Mar 2, 2021 at 9:25 AM
On Tue, Mar 2, 2021 at 4:47 AM Mark Andrews wrote:
>
> > On 2 Mar 2021, at 23:06, Ulrich Wisser wrote:
> >
> >
> >
> >> On 2 Mar 2021, at 12:55, Mark Andrews wrote:
> >>
> >>
> >>
> >>> On 2 Mar 2021, at 22:52, Ulrich Wisser wrote:
> >>>
> >>> @Håvard No, that isn’t sufficient. A resolver coul
On Mon, Mar 1, 2021 at 7:46 AM Ulrich Wisser wrote:
> Hi Jim,
>
> I don’t want to signal this to resolvers, there is no need to. As domains
> are resolved by themselves a resolvers doesn’t need to know if all other
> subdomains of .se are signed too, just that the one it is interested in is
> sig
On Wed, Feb 24, 2021 at 2:14 PM Ben Schwartz wrote:
>
>
> On Wed, Feb 24, 2021 at 4:44 PM Mark Andrews wrote:
>
>>
>>
>> > On 25 Feb 2021, at 02:01, Ulrich Wisser > 40wisser...@dmarc.ietf.org> wrote:
>>
> ...
>
>> > At the current state of dnssec RFC definitions it is unclear how you
>> could ch
On Tue, Feb 23, 2021 at 8:50 AM Ben Schwartz wrote:
>
>
> On Tue, Feb 23, 2021 at 11:21 AM Samuel Weiler wrote:
> ...
>
>> Recognizing that I'm likely biased by my history of working on the
>> current "mandatory algorithm rules", I don't buy the need for this
>> complexity. In practice our "wea
I like this proposal, look forward to experimenting with this.
I'm not sure about how to defend against downgrade attacks, without
potentially having to touch some other DNSSEC-specific standards. I admit
to not having looked at them again, recently, with this in mind, so the
question I'm asking i
On Thu, Jan 21, 2021 at 3:45 AM Peter van Dijk
wrote:
> On Thu, 2020-12-10 at 15:48 -0800, Brian Dickson wrote:
> > >
> > > Compared to DiS, registrar complexity is identical (because the
> > > complexity is also hidden in the signer here); signer complexity is
>
On Tue, Jan 5, 2021 at 2:29 PM Eric Orth wrote:
> Besides future-proofing for potential changes, I think the current rule
> keeps us more flexible for handling obscure cornercases. If there's any
> reasonable chance that some obscure usecase in the future might make it
> difficult for an authori
Without going into the original discussion (whether or not to reserve some
sub-range of code points for some purpose or another), I'd like to suggest
a method to use that conserves values better.
This would apply to any very limited resource (such as code points) within
a linear range.
It would bas
On Thu, Dec 10, 2020 at 4:52 PM Joe Abley wrote:
> On 10 Dec 2020, at 19:41, Paul Hoffman wrote:
>
> >> "Authenticate authoritative servers" is a bit vague for me. Parent and
> child are namespace concepts and not relying parties that you'd ordinarily
> expect to be able to authenticate anything
On Thu, Dec 10, 2020 at 1:19 PM Peter van Dijk
wrote:
> Hello Paul,
>
> On Mon, 2020-11-30 at 15:43 +, Paul Hoffman wrote:
> > The more I think about
> draft-fujiwara-dnsop-delegation-information-signer, the more I think that
> it is much more complex than what we are doing now in DNSSEC, and
would need to include all potential values of the
timestamp over the cookie lifetime.
I believe the 30 minutes or 1 hour lifetime adds enough entropy to
significantly increase the work required for a brute force attack.
I don't think the absolute size of the timestamp value (in b
On Wed, Dec 2, 2020 at 1:49 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 02/12/2020 21:38, Willem Toorop wrote:
> > Op 02-12-2020 om 21:37 schreef Stephen Farrell:
> >
> >
> >
> >>> ad 2) we need a value that’s synchronized well enough and monotonic.
> >>> I honestly don’t see any value in using 6
On Thu, Nov 19, 2020 at 9:35 AM Ben Schwartz wrote:
>
> I do not support the geolocation function. I think the right solution
> here is ECS. Even bad IP-geolocation from ECS will be better than using
> the recursive resolver's country-code; at least it will be estimating the
> location of the r
On Tue, Nov 17, 2020 at 1:46 PM Tony Finch wrote:
> Brian Dickson wrote:
>
> > One potential approach is to say (in the RFC) that one of the two-letter
> > reserved codes should avoid name collision by putting a
> collision-resistant
> > second-level label, below .z
Comments made in the chat, about the private-use presentation/draft:
Me:
One potential approach is to say (in the RFC) that one of the two-letter
reserved codes should avoid name collision by putting a collision-resistant
second-level label, below .zz and above the private use usage (and use that
p
On Tue, Oct 27, 2020 at 5:33 PM Tim Wicinski wrote:
>
> All,
>
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc7816bis
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/
>
> The Current Intended Status of this docum
On Fri, Oct 9, 2020 at 8:38 AM Benno Overeinder wrote:
> This starts a Working Group Last Call for draft-ietf-dnsop-server-cookies.
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/
>
> The Current Intended Status of this docu
On Tue, Oct 6, 2020 at 6:10 PM Ben Schwartz wrote:
> On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>> Other than the syntactic brevity, is there any functional difference to
>> the client between a TargetName of &quo
On Fri, Sep 25, 2020 at 5:36 AM Peter van Dijk
wrote:
> Hello dnsop,
>
> in this new episode of 'enabling future innovations that we perhaps
> cannot even imagine today', please find below a link to a draft
> proposing a DS digest type that does no digesting at all. This allows a
> zone owner to
On Thu, Sep 24, 2020 at 10:58 AM Peter van Dijk
wrote:
> Hello dnsop,
>
> early 2019, Manu of Facebook proposed the DSPKI record - a parent-side-
> of-the-delegation record to hold a pin for authenticating child-side
> DoT servers. This would be undeployable.
>
> A few months ago, Tim April propo
On Fri, Aug 7, 2020 at 7:20 AM Andrew McConachie wrote:
>
>
> On 6 Aug 2020, at 16:41, Paul Hoffman wrote:
>
> > On Aug 6, 2020, at 4:08 AM, Andrew McConachie
> > wrote:
> >>
> >> What does it mean for a resolver to be primed, or for a resolver to
> >> not be primed? For example, is a resolver c
On Fri, Sep 11, 2020 at 5:16 PM Paul Hoffman wrote:
> On Sep 11, 2020, at 4:40 PM, Mark Andrews wrote:
> >
> > and why is it a RR type at all.
>
> So that the answer can be signed and thus validated.
>
> > An EDNS option or a opcode is better suited for this sort of thing.
>
> What advantages do
On Tue, Aug 11, 2020 at 2:38 PM Ben Schwartz wrote:
>
>
> On Tue, Aug 11, 2020 at 4:54 PM Tony Finch wrote:
>
>> Ben Schwartz wrote:
>> >
>> > 1. If TargetName is not in-bailiwick and is not ".", terminate the
>> procedure.
>> > 2. If SvcPriority is 0:
>> > * If TargetName is ".", terminate
On Fri, Aug 7, 2020 at 7:42 AM Ben Schwartz wrote:
>
>
> On Fri, Aug 7, 2020 at 4:14 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>
>> "More than one is permitted" is the case only because of the current spec.
>> I don't see a
On Thu, Aug 6, 2020 at 9:42 PM Mark Andrews wrote:
>
> Sorry you just broke DNSSEC if there are more than one AliasForm records.
> More than one is permitted with the same name.
>
Good point.
"More than one is permitted" is the case only because of the current spec.
I don't see any explanation
On Thu, Aug 6, 2020 at 7:13 PM Ben Schwartz wrote:
> Brian,
>
> I think arguing about the strength of the analogies to CNAME (Answer) vs
> SRV (Additional) is going to be a slow path to consensus. Apart from that
> analogy, I'm not sure I understand your motivating use case. Could you
> write a
On Thu, Aug 6, 2020 at 4:11 PM Mark Andrews wrote:
>
>
> What benefit is there in changing this now? Moving the SVBC chain (graph
> actually) to the answer section. I know I can follow a graph much easier
> in the additional section than I can in the answer section with simple
> depth limited r
On Thu, Aug 6, 2020 at 6:22 AM Mark Andrews wrote:
>
>
> I really don’t know how this thread got started with clear and unambiguous
> instructions to add all the records to the additional section.
>
The possibility of changing what is specified in the draft, was what
started this thread.
Your re
On Wed, Aug 5, 2020 at 10:08 AM Ben Schwartz wrote:
> On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis
> wrote:
> ...
>
>> Do *both* alias-target{1,2}.example.net|SVBC records end up in the
>> ADDITIONAL section. Or are they (as is the case with an in-zone CNAME)
>> considered an answer and should t
On Thu, Jul 30, 2020 at 1:44 PM Joe Abley wrote:
>
> There are some 20,000 examples in the ORG zone, of which at least 7,000
> are due to the domain suspension mechanism I gave as an example. There are
> lots of well-functioning domains that would fail if all of those A/
> records suddenly st
On Thu, Jul 30, 2020 at 1:21 PM Joe Abley wrote:
>
> $ORIGIN ORG.
>
> BADDOMAIN NS ...
> BADDOMAIN NS ...
> NS1.BADDOMAIN A 192.0.2.1
>
> GOODDOMAIN NS NS1.BADDOMAIN.ORG.
> GOODDOMAIN NS ...
>
> If BADDOMAIN.ORG is suspended (or if the domain is suppressed for some
> equivalent reason) then the z
On Wed, Jul 22, 2020 at 6:41 PM Ben Schwartz wrote:
> On Wed, Jul 22, 2020 at 9:20 PM Wellington, Brian 40akamai@dmarc.ietf.org> wrote:
>
>> ok. So, what this means is that keys listed in the “mandatory” parameter
>> must be included as parameters, and are required to be understood by
>> cl
On Wed, Jul 15, 2020 at 10:16 AM Erik Nygren wrote:
> We landed on 63 in the draft version we just published (to align with max
> label lengths).
> There's no reason they *need* to be short as they are just in presentation
> form, so their length
> comes down to usability and finding the right w
(Apologies for any weird quoting-style/depth issues, mail user agents
aren't terribly consistent.)
On Thu, Jul 9, 2020 at 8:03 PM Mark Andrews wrote:
>
>
> > On 10 Jul 2020, at 11:53, Joe Abley wrote:
> >
> > On 9 Jul 2020, at 18:48, Mark Andrews wrote:
> >
>
> > By that logic, DNS UPDATE chan
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
On Fri, Jul 3, 2020 at 3:03 PM John R Levine wrote:
> On Fri, 3 Jul 2020, Brian Dickson wrote:
> > It makes clear the difference between implied and inferred.
> > The flag clearly indicates that some glue which would otherwise be
> > considered necessary has not been sent.
On Fri, Jul 3, 2020 at 10:59 AM John Levine wrote:
> In article <
> cah1icirmlslmohchqcvqis6ra0myk40ejsdm_b5pmxagxrn...@mail.gmail.com> you
> write:
> >There are a whole bunch of unused bits in the core element of the OPT RR
> >(the place where the DO bit exists). That would be an excellent (IMHO
On Thu, Jul 2, 2020 at 9:14 AM Paul Hoffman wrote:
> The interpretation of whether a partial RRset is allowed by 1035/2181 made
> by JohnL, PaulV, and MukundS are all plausible and conflicting. RFC 1035
> and RFC 2181 are unclear about whether an RRset that is required in a reply
> can be partial
101 - 200 of 387 matches
Mail list logo
