this is essentially a bar bof - though lacking in a bar and I'm fond of
more professional terms so I call it a side meeting. It has no standing. If
you're interested then please come, if you're not or are conflicted then
you're missing anything process wise.
Someday it might graduate to becoming
Hi All,
I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in
Montreal.
We have often talked about the benefits and concerns of DNS information
obtained from sources that are, shall we say, less globally trusted than a
recursive a resolver. The central use case is DoH when
What I want is the nexus of OOB "file" form zone download and
integrity check which is cheap to implement signer and receiver.
I was on PGP. Duane has taken me to an RR which is a sequenced,
canonicalized digest, which then is under the ZSK sign of the zone.
For the root, it feels doable. For
> On 10 Jul 2018, at 10:22 am, George Michaelson wrote:
>
> Yea, having read things properly and been hit by a cluestick I think
> this is good.
>
> * the RR is a digest over canonicalized state
>
> * there is a simple method to take zone, re-canonicalize (its the
> DNSSEC order) and check
I got a bit wound up about not making the three changes that Joel called out in
the updated session signal comment, and insisted on not making the changes
because they didn't seem that important. I had a bit more private
conversation with Joel about it, and after some reflection decided that
Yea, having read things properly and been hit by a cluestick I think
this is good.
* the RR is a digest over canonicalized state
* there is a simple method to take zone, re-canonicalize (its the
DNSSEC order) and check the digest
* since the RR is covered by the ZSK signing, the entire zone is
George,
> On Jul 9, 2018, at 4:36 PM, George Michaelson wrote:
>
> There's arguments both sides about cross signing, counter signing and
> independent self-signing. If you want to promote out of band zone
> exchange, it has to be signed. The key it signs with is immaterial if
> you either
There's arguments both sides about cross signing, counter signing and
independent self-signing. If you want to promote out of band zone
exchange, it has to be signed. The key it signs with is immaterial if
you either direct knowledge of the PK in a PKI, or accept a trust
anchor relationship over
Thanks to all who commented. The WGLC is over and the chairs have seen strong
support for this document and lots of participation in getting it right, so
we’ll be advancing it for publication.
The authors will be spinning up a new version, incorporating the last call
comments, and we’ll submit
> On Jul 8, 2018, at 8:39 PM, Olafur Gudmundsson wrote:
>
> So the followup question is
> Should we burden the Auth Server implementations with this calculation if the
> usage case if 4 zones ?
> or is this better handled by external tools ?
> DNS Camel says ?
IMO we should build something
> On Jul 8, 2018, at 6:02 PM, George Michaelson wrote:
>
> So how about use of a PGP key which is a payload in TXT signed over by
> the ZSK/KSK so the trust paths bind together?
>
> fetch one DNS record +sigs, check against the TA (which has to be a
> given) and then..
Currently in the zone
> On Jul 8, 2018, at 5:28 PM, Olafur Gudmundsson wrote:
>
>
> +1
> I spent lots of time earlier this century along with Johan Ihren trying to
> figure out how to
> secure the transfer of a particular zone (the root) to any resolver.
> The only sane way is to not transfer the zone over AXFR
On 9 July 2018 at 19:48, Dave Crocker wrote:
>8
> Does this cause anyone intolerable heart-burn? If it does, please at
> least explain but preferably offer something better.
>
I do not suffer from intolerable heart-burn but happy to offer:
If a public specification calls for the use of an
On 7/9/2018 2:09 PM, John Levine wrote:
Since it'll always be on the right for people reading this document in English,
I'd rather leave it alone.
Except that a) RFCs get translated, and b) people implement RFCs all
over the world, including places that display rtl. (cf, 'robustness'.)
d/
In article <9ab5e7e3-2959-2e3c-135d-d749e0aa6...@dcrocker.net> you write:
>to:
> If a public specification calls for use of an
> _underscore-prefixed domain node name, the 'global'
> (highest level, and typically right-most) _underscored name MUST
> be entered into
On 7/6/2018 8:22 AM, Stephane Bortzmeyer wrote:
On Mon, Jun 25, 2018 at 12:27:17PM +0200,
Benno Overeinder wrote
a message of 27 lines which said:
This starts a Working Group Last Call for draft-ietf-dnsop-attrleaf
I've read -10 and it seems OK. It solves a real issue, and does it
I'm with you, ideally they should use DHCPv6 ... so tell them :-)
Regards,
Jordi
-Mensaje original-
De: en nombre de Philip Homburg
Fecha: lunes, 9 de julio de 2018, 18:26
Para:
CC: JORDI PALET MARTINEZ
Asunto: Re: [DNSOP] AD sponsoring
> I think deprecating
> RFC7050 will be a bad idea, there are too many implementations that
> really need that, while updating APIs/libraries to make sure they
> comply with this seems easier.
>
> For example, we could have a DHCPv6 option, but in the cellular
> world DHCPv6 is not used ... and
Tim/Suzanne -
Please cancel the request for publication until you complete the WGLC
for this document.
The last WGLC for the document was October of last year - it failed on
28 October
https://www.ietf.org/mail-archive/web/dnsop/current/msg21225.html. No
WGLC has been made since then.
Hi all,
Procedure/process update.
As announced, the WG LC should/would be closed today, but draft
reviewers suggested to run attrleaf and attrleaf-fix together through
the process. The WG LC will be closed this Wednesday, July 11th for
both attrleaf and attrleaf-fix.
-- Benno
On 07/07/2018
Anthony Eden 于2018年6月20日周三 上午12:06写道：
> On Tue, Jun 19, 2018 at 4:47 PM, Lanlan Pan wrote:
>
>>
>>
>> Petr Špaček 于2018年6月19日周二 下午9:19写道：
>>
>>> Hello dnsop,
>>>
>>> beware, material in this e-mail might cause your head to explode :-)
>>>
>>> This proposal is based on following observations:
>>>
21 matches
Mail list logo
