On Thursday, March 12, 2015 12:39:17 PM Florian Weimer wrote:
On 03/12/2015 11:36 AM, Jan Včelák wrote:
And does anyone actually use opt out with NSEC3?
Yes, .com for example. My impression was that Opt-Out was the selling
point of NSEC3, not the domain name hashing.
Okay
On 11.3.2015 17:30, Florian Weimer wrote:
On 03/11/2015 05:19 PM, Jan Včelák wrote:
It's not clear if the security goals make sense. What do zone operators
gain if zone enumeration attacks are moved from offline to online, other
than a need to provision additional server capacity? It's
Hello Florian,
On 11.3.2015 12:01, Florian Weimer wrote:
do you plan to submit this to an IETF working group, or as an individual
submission?
We plan to submit the draft as an individual submission.
It's not clear if the security goals make sense. What do zone operators
gain if zone
On Wednesday, March 11, 2015 09:52:55 AM Nicholas Weaver wrote:
Why not just do something simpler? The only thing NSEC5 really differs in a
way that counts is not in the NSEC record but really just the DNSKEY
handling, having a separate key used for signing the NSEC* records.
So why define
On 24.3.2015 21:25, Paul Wouters wrote:
On Tue, 24 Mar 2015, Jan Včelák wrote:
The contents of zones quickly becomes visible, what with passive DNS,
DITL, people who connect in place X, and then reopen their laptop in
place Y, etc.
I know and I completely agree.
On the other hand
On 24.3.2015 13:57, Paul Hoffman wrote:
On Mar 23, 2015, at 6:23 PM, Jan Včelák jan.vce...@nic.cz wrote:
This proposal continues to have fundamental problems that are not
documented in the draft.
- The statement about NSEC3 offline dictionary attacks are still possible
and have been
On 24.3.2015 21:04, Bob Harold wrote:
But for the servers and public to know which key to use, there will need
to be some id that matches NSEC5 records to the matching NSEC5 key.
That requires changing the format of the NSEC5 records, so it cannot be
done later.
You
On 26.3.2015 07:26, Paul Vixie wrote:
Evan Hunt wrote:
On Wed, Mar 25, 2015 at 05:24:32PM -0700, Paul Vixie wrote:
...
that would be an overspecification. the spec should simply say any
RRset, where the choice of which RRset is implementation-dependent.
some might go for oldest; some
Hi,
I just submitted an updated NSEC5 draft into the data tracker. The most
significant change is fixing the NSEC5 key rollover mechanism; the rest
are just typo fixes and small clarifications in terminology.
http://datatracker.ietf.org/doc/draft-vcelak-nsec5/
Also, I will have a 10 minute talk
On 24.3.2015 19:11, Warren Kumari wrote:
On Tue, Mar 24, 2015 at 9:56 AM, Jan Včelák jan.vce...@nic.cz wrote:
On 24.3.2015 13:57, Paul Hoffman wrote:
On Mar 23, 2015, at 6:23 PM, Jan Včelák jan.vce...@nic.cz wrote:
This proposal continues to have fundamental problems that are not
documented
On 24.3.2015 20:08, Bob Harold wrote:
On Mon, Mar 23, 2015 at 6:38 PM, Jan Včelák wrote:
On 23.3.2015 18:26, Bob Harold wrote:
I think we might need to allow for more than one NSEC5 key and chain,
during a transition. Otherwise it might be impossible to later create
On 24.3.2015 19:20, Paul Hoffman wrote:
Again: a proposal for an operational change to DNSSEC needs to be explicit
about the tradeoffs, particularly when one of the options is you will be
considered unsigned by some resolvers when you implement this. The current
draft is not have this.
On 23.3.2015 18:26, Bob Harold wrote:
I think we might need to allow for more than one NSEC5 key and chain,
during a transition. Otherwise it might be impossible to later create a
reasonable transition process. This might require us to tag the NSEC5
records with an id, so that the chains and
Hi Paul,
This proposal continues to have fundamental problems that are not documented
in the draft.
- The statement about NSEC3 offline dictionary attacks are still possible
and have been demonstrated doesn't take into account trivial changes that an
operator can choose to take if they
>> * Perhaps "Accept with challenge" should provide some advice on how
>> this works. For example, a TXT record with a unique key for each zone
>> (or customer) seems like a good recommendation. It might also make
>> sense if each child domain (or customer) has a unique ownername to
>> look
Hi Mikael,
> I via these found RFC4035:
>
> "If the resolver does not support any of the algorithms listed in an
>authenticated DS RRset, then the resolver will not be able to verify
>the authentication path to the child zone. In this case, the
>resolver SHOULD treat the child zone
On Tue, Mar 28, 2017 at 4:41 AM, Evan Hunt wrote:
> We can and should kill MD5 key generation and signing (and I'll add this to
> the ticket about updating defaults in BIND) but I'm uncomfortable killing
> MD5 validation until I'm sure there aren't any legacy keys floating around.
Short history
On Fri, Apr 7, 2017 at 8:11 PM, Evan Hunt wrote:
> Here's the new ANAME draft I mentioned last week.
Hey, thanks for this one! I support the attempt to define a record
type that would cover the existing vendor-specific types that
synthesize A/ records in zone apex. If this gets adopted by the
I'm not sure if this discussion is moving forward.
CDS/CDNSKEY RDATA format is the same as DS/DNSKEY RDATA format per
definition in Section 3 of RFC 7344. Although DS Digest field and
DNSKEY Public Key field can be zero-length on wire, the presentation
format is underspecified and it practically
Hello,
sorry for resurrecting this thread, but this really caught my attention.
On Wed, Apr 5, 2017 at 9:03 AM, Peter van Dijk wrote:
> On 5 Apr 2017, at 7:43, Mukund Sivaraman wrote:
>> Evan just pointed out a case due to a system test failure that is
>> interesting.. it's not clear what the
On Thu, Apr 27, 2017 at 1:04 AM, Mark Andrews wrote:
>
> In message
>
I agree that the errata is correct.
It is maybe suboptimal that wire format for DS/DNSKEY delete-request
was not specified in the document. And I'm not sure if the authors
meant that the digest/public key is zero-length or one-byte long. But
luckily this can prevent some compatibility issues:
> It's also their intransigence re: SRV which has caused the CNAME at the
> Apex issue. CNAME was *never* the right answer for doing application
> level indirection in HTTP space.
SRV also trades CNAME at apex for wildcard names support. There is a
plenty of services that employ wildcards to
Hey,
I just scanned the draft and focused mainly on the DNS bits. The
described method for publishing encryption keys for SNI in DNS won't
allow use of wildcard domain names.
Relevant text in the draft:
The name of each TXT record MUST match the name composed of _esni and
the query domain
:53 PM, Tim Wicinski wrote:
>>
>> Patrick
>>
>> Can I go and order a SSL Cert with a standard name and a wildcard name for
>> SNI? We do that now.
>>
>> So, I think Jan is onto something.
>>
>>
>> On Thu, Jul 19, 2018 at 1:47 PM, Pat
On Thu, Jul 19, 2018 at 3:04 PM Kazuho Oku wrote:
> Background: In ESNI, we would like to support two types of
> deployments: 1) DNS and TLS servers operated by same entity, 2) DNS
> and TLS server operated by separate entities.
Let me sketch how this could work with custom DNS record type. Let's
On Thu, Jul 19, 2018 at 4:56 PM John Levine wrote:
> It's harder to deploy a new rrtype than an overloaded TXT record, but
> you can't have everything.
Just a note that IANA action will be soon (eventually) required to use
underscore label:
> This starts a Working Group Last Call for draft-ietf-dnsop-attrleaf
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
I've read the document and I agree all comments were addressed. Thumbs up.
Jan
mittee:
https://www.dns-oarc.net/oarc/programme
via
Jan Včelák, for the DNS-OARC Programme Committee
OARC depends on sponsorship to fund its workshops and associated social
events. Please contact if your organization is
interested in becoming a sponsor.
(Please note that OARC is run on
On Fri, Mar 29, 2019 at 9:58 PM Tony Finch wrote:
> There were several useful points at the mic; thanks Paul Hoffman for
> noting them in the minutes (especially because I could not remember who
> said what). In no particular order...
Tim also mentioned that the vendors have their own secret
On Fri, Apr 26, 2019 at 8:30 PM 神明達哉 wrote:
> > Jan Včelák mentioned that at least NS1 uses a different order of
> > priority: If an sibling address record exists next to the ANAME it takes
> > precedence and no target lookup is done for that address record type.
>
> if the
Hello.
I would like to resurrect the discussion about ANAME loops handling
and detection. I attempted to write a discussion section on this topic
for draft-ietf-dnsop-aname
[https://github.com/each/draft-aname/pull/70] and we also talked about
this a little off-list with Shane and Matthijs.
If
On Thu, Jul 4, 2019 at 4:55 PM Matthijs Mekking wrote:
> On 7/4/19 2:32 PM, Matthew Pounsett wrote:
> > I would say they should rely on that. Why shouldn't they? Isn't our
> > goal to get downstream servers to adopt the extension and do their own
> > lookup? The server-side lookups and sibling
On Tue, Apr 2, 2019 at 5:54 PM Tony Finch wrote:
> WRT loop detection, it is much easier if the additional section in the
> response from the resolver contains the chain(s). The draft doesn't
> specify that at the moment; maybe it should.
I meant a situation where an authoritative server is doing
sments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.
If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via
Jan Včelák, for the DNS-OARC Pro
On Wed, Sep 25, 2019 at 7:17 PM Ben Schwartz wrote:
>> example.com. 7200 IN HTTPSSVC 0 svc.example.net. ""
>> svc.example.net. 7200 IN HTTPSSVC 2 svc3.example.net. "alpn=h3
>> port=8003 esnikeys=\"ABC...\""
>
>
> The original proposal used a text encoding similar to your description. We
Matthijs,
On Mon, Jul 8, 2019 at 11:47 AM Matthijs Mekking wrote:
> >> Also what is wrong with an authoritative server already giving out more
> >> optimal answers than just the ANAME and sibling address records?
> >
> > I also understand the sibling address records only as a mean to gap
> > the
ou can contact the Programme
Committee via submissi...@dns-oarc.net
Jan Včelák, for the DNS-OARC Programme Committee
OARC depends on sponsorship to fund its workshops and associated
social events. Please contact spon...@dns-oarc.net if your organization
is interested in becoming a sponsor. OARC
On Tue, Sep 24, 2019 at 3:19 PM Erik Nygren wrote:
> Following discussions around the "HTTPSSVC" record proposal in Montreal with
> the DNSOP, HTTP and TLS WGs, we've updated what was previously
> "draft-nygren-httpbis-httpssvc-03". The new version is
> "draft-nygren-dnsop-svcb-httpssvc-00".
questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via
Jan Včelák, for the DNS-OARC Programme Committee
OARC depends on sponsorship to fund its workshops and associated social
events. Please contact if your organization is
interested in becoming
> Abstract:
>The DNS uses glue records to allow iterative clients to find the
>addresses of nameservers that live within the delegated zone. Glue
>records are expected to be returned as part of a referral and if they
>cannot be fitted into the UDP response, TC=1 MUST be set to
> > I also think there is another proprietary implementation of an
> > authoritative server in the wild which implements similar policy. It
> > picks a small random subset of the NS records and adds A/ just for
> > these names. If the QNAME matches a name in the NS, A/ for that NS
> > is
42 matches
Mail list logo
