Hello everyone,
Speking as the author of RFC 7830 – there was some discussion whether the
document should say “SHOULD NOT” or “MUST NOT” when padding DNS packets over
unencrypted packets. We couldn’t come up with any other use case (maybe except
testing of the feature over unencrypted transport
Setting the basic issue aside (I'm still a bit torn) I agree with
Warren that it would need a string that has a meaning.
..ZZ would remind me of long beards and loud motorcycles for the rest
of my life.. https://de.wikipedia.org/wiki/ZZ_Top
best,
Alex
Wes, all,
thanks for putting together draft-ietf-dnsop-nsec3-guidance. I have
one small comment regarding section 2.2 (Flags):
In some deployments of larger (eg TLD), in-memory zone size on the
authoritative servers is a significant issue, particularly if the
total memory size required is multipl
On Wed, Nov 15, 2017 at 9:57 AM, Dave Lawrence wrote:
> I personally am of the belief that yes, if the request has an OPT then
> a responder can include an option code that was not in the request.
> At least I don't see anything in 6891 to prohibit it. This is
> behaviour that draft-ietf-dnsop-ex
> I'm not particularly arguing either way on this question of signalling,
> but do we have any feel for how many stubs ever send EDNS?
>
> libresolv can do it, and getdns does, but I don't think glibc's resolver
> routinely sends EDNS.
Ray,
i do agree - having figures "from the field" about this
ion Notification for draft-mayrhofer-did-dns-00.txt
To: Dimitrij Klesev , Alexander Mayrhofer
, Markus Sabadello
A new version of I-D, draft-mayrhofer-did-dns-00.txt
has been successfully submitted by Alexander Mayrhofer and posted to the
IETF repository.
Name: draft-mayrhofer-did-dn
Hello Benno,
I'd like to talk about
https://tools.ietf.org/html/draft-mayrhofer-did-dns-00. I think i
should be good with 5 minutes.
much appreciated!
Alex
On Tue, Oct 2, 2018 at 11:15 PM Benno Overeinder wrote:
>
> Hi all,
>
> We have requested one DNSOP session of 2 hours for the IETF 103. T
Hello everyone,
I'm turning my head around an issue around the attrleaf draft, and its
connection with RFC7553 (the URI RRType). Im specifically wondering what the
connection between the "service parameter" in RFC 7553 and the "Global
Underscore Node Names" in draft-ietf-dnsop-attrleaf is. I'm
Hi,
> Von: Paul Hoffman
> Gesendet: Donnerstag, 7. Februar 2019 22:45
[..]
> > Dave moved the duct tape patching up all the places that defined
> > underscored names to draft-ietf-dnsop-attrleaf-fix.
> >
> > See sections 2.3 and 2.3 for URI records.
> >
Oh, i should have looked at the attrleaf
2019 at 2:52 PM
Subject: New Version Notification for draft-mayrhofer-did-dns-01.txt
To: Dimitrij Klesev , Alexander Mayrhofer
, Markus Sabadello
A new version of I-D, draft-mayrhofer-did-dns-01.txt
has been successfully submitted by Alexander Mayrhofer and posted to the
IETF repository.
Name:
Stephane, all,
[I feel cautious about continuing to cross-post this to dnsop as well
as dinrg - however, it does apply to both areas, so i'll keep both
groups in for now]
On Fri, Feb 15, 2019 at 10:37 AM Stephane Bortzmeyer wrote:
> I think that it is an important work because it brings the powe
Paul,
On Fri, Feb 15, 2019 at 7:47 PM Paul Wouters wrote:
> I think this document should be Experimental and not Standards Track?
I was torn when i did the first revision of this. I think it depends
on the stability of Decentralized Identifiers themselves. Once that
schema becomes widely used, i
On Fri, Feb 15, 2019 at 8:47 PM Melinda Shore
wrote:
> I think the question of whether or not to provide
> decentralized identifiers and whether or not this proposal
> delivers on the "decentralized" claim is out of our hands,
> as the core spec (which has a lot of additional problems)
> comes out
lex
Von: Alexander Mayrhofer
Gesendet: Dienstag, 26. März 2019 11:13
An: reg...@ietf.org
Betreff: Security/Registry Lock Side Meeting: Wed, 14:00 - 15:00, Room Paris
Hello everyone,
as mentioned during the regext WG session, i've organized a "SecurityLock /
RegistryLock" side meeting
Hi,
I had a discussion with Daniel Khan Gillmor today, and we talked about his
proposal to specify a padding option in TLS so that message-size based
correlation attacks on encrypted DNS packets could be prevented. We continued
discussing other options (such as "artificial" RRs in the addition
George,
i certainly agree. Noted for a revision.
Alex
Von: George Michaelson [mailto:g...@algebras.org]
Gesendet: Donnerstag, 23. Juli 2015 18:52
An: Alexander Mayrhofer
Cc: dns-priv...@ietf.org; dnsop@ietf.org
Betreff: Re: [DNSOP] draft-mayrhofer-edns0-padding
What does it mean to exceed the
As mentioned in the session today, the Enumservices Guide contains some
text on DNS Considerations in section 5.7:
http://tools.ietf.org/html/draft-ietf-enum-enumservices-guide
The original reason for this text was the "unused" Enumservice, which
conveyed assumptions about the DNS space "below"
Hi,
I've volunteered in Philly to do a review of the response size drafts -
i have seperated my comments into "content" and "nits" issues.
content
---
- The first sentence in 2.1 should probably start with "A positive
delegation response.." because a negative response could for example
als
> that's all i found --
hm. i knew i forgot something:
References: I guess that most of the "Normative" References in the draft
could be made "Informative". The only normative ones i see are RFC1034,
RFC1035, and RFC2181. The others should be moved to an Informative
References section.
thanks,
> You may be quite right about that. It's one of the things that I want
> to have a discussion about. I started out with a somewhat conservative
> specification, to see where the discussion will take us.
>
> More voices?
I would keep the ABNF to purely *technical* limits as well. Don't let
the AB
Hi,
We've been discussing internally whether or not including DS records into a
zone without respective NS record(s) makes any sense (assuming that there are
no other RRSETs for the respective label in the zone itself - pure "delegation"
scenario)... My personal assumption is that it does not,
Tim,
> We have decided after much discussion (and little negative feedback) to hold
> a seperate session Thursday Evening at 16:40 to discuss DNS privacy and all
> the things that come with it.
Is that the correct time? The Agenda does list time slots starting at either
17:00 or 18:40 - are you
Hi,
I've reviewed the keepalive draft. Generally, i do like the concept a lot
because: a) there's certainly a use case that covers real operational issues
b) it's a space-efficient and c) unobstrusive. However, i think the document
could improve on clarity in certain aspects - see below for d
> * PROTOCOL: Is the expected behaviour (MUST) from both client and server
> that they should add the Option to every single request / response during a
> keepalive session? Please clarify the intended behaviour..
Two final comments, sorry:
* EDITORIAL/PROTOCOL: Shouldn't the option (as well as t
24 matches
Mail list logo