Chairs,
Quick questions
why a new list and what is that lists standing in the IETF?
Is this precursor for a BOF and possible new working group ?
thanks
Ólafur
On Tue, Feb 6, 2024 at 2:37 PM Paul Hoffman wrote:
> Greetings. After the DNSOP interim meeting last week, Warren set up a new
> maili
Peter,
I like the concept a lot and this is a good natural evolution,
My comments/issues
#1 this should cover normal notify as well as there is no reason parent
should have to be updates every time an external DNS provider changes its
distribution "top"
#2 I would love the examples to use a diff
Parent is authoritative for the existence of the delegation
Child is authoritative for the contents of the delegation
DNS design did not take this into account thus there is no "range" of
Parent only records,
DS is the only record that is explicitly a "violation" of this
IMHO RFC103x should have
t; form, so their length
> comes down to usability and finding the right words. The longest
> currently is 15 and it would
> be better to avoid future ones needing to be artificially constrained. Is
> there a reason we'd
> want to decrease this (eg, to 31)?
>
> On Wed,
How about 2 or 10 ?
why do the names to need to be long ?
Olafur
On Thu, Jul 9, 2020 at 10:18 PM Erik Nygren wrote:
> Or 64?
>
>
>
> - Erik
>
> [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
>
> On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz 40google@dmarc.ietf.org> wrote:
>
I read the draft and like it, this is a clear statement of the problem and
good way forward.
I agree with the idea that "all" NS are lame is a good signal to
revalidate,
One idea to throw out here triggered by the first two paragraphs in section
3
Should we recommend that Authoritative servers tha
On Tue, Jan 7, 2020, 8:18 AM Viktor Dukhovni wrote:
> On Tue, Jan 07, 2020 at 02:54:43PM +, Tony Finch wrote:
>
> > The third paragraph of the abstract suggests this is relevant to DNSSEC
> RSASHA1:
> >
> > https://eprint.iacr.org/2020/014
>
> [ I've Bcc'd the authors, perhaps they'll follow
On Thu, Nov 14, 2019 at 6:40 AM Shane Kerr
wrote:
> Hello,
>
> We just implemented DNAME support on an authoritative server that
> already implements giving an HINFO response to ANY queries, as described
> in RFC 8482.
>
> RFC 8482 is clear about not allowing the HINFO response if there is a
> CN
On Mon, Jul 22, 2019 at 2:00 PM Dan Mahoney wrote:
> After a hallway conversation with Evan yesterday, I wanted to clarify a
> few things that I came across when working on this. Point one is the
> use-case of NOTE. Point two is an argument for the general usefulness of
> a COVERT record.
>
> O
I think this is a good clarification
Olafur
On Thu, Feb 28, 2019 at 8:53 AM Peter J. Philipp wrote:
> Hi again,
>
> Well I ended up fixing it myself yesterday through a lot of trial and
> error and finally understanding the
>
> RFC. I recommend the following change to make it easier for future
Tim,
I have reviewed the document and it is ready for publication
Olafur
On Tue, Oct 2, 2018 at 2:51 PM Tim Wicinski wrote:
>
> The chairs and the authors of this document feel that the
> document is in solid shape to proceed to WGLC.
>
>
> This starts a Working Group Last Call for draft-ietf-
Jinmei explained perfectly what I was trying to say
Olafur
On Fri, Sep 14, 2018 at 5:25 AM, 神明達哉 wrote:
> At Thu, 13 Sep 2018 17:25:04 +0200,
> "Mirja Kuehlewind (IETF)" wrote:
>
> >>> I'm wondering if it would make sense to provide stronger guidance that
> the
> >>> conventional ANY response
On Thu, Sep 13, 2018 at 9:13 AM, Benjamin Kaduk wrote:
> Hi Ólafur,
>
> Before I get into the inline comments, I should note something that I only
> noticed after I posted my ballot position: although everyone I know always
> refers to this query as "ANY", that's the command-line interface in dig
On Mon, Sep 10, 2018 at 11:27 PM, Mirja Kühlewind
wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to
On Tue, Sep 11, 2018 at 10:27 AM, Adam Roach wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to
On Tue, Sep 11, 2018 at 1:48 AM, Benjamin Kaduk wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cu
On Thu, Sep 13, 2018 at 7:15 AM, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel fre
On Thu, Sep 13, 2018 at 2:56 AM, Alexey Melnikov
wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel
Ted,
Would it be acceptable to just do
s/TCP/Connection oriented Transport/
Olafur
On Tue, Aug 21, 2018 at 12:48 PM, Ted Hardie wrote:
> Howdy,
>
> I note that section 4.4 calls out TCP transport and says this:
>
> 4.4. Behaviour with TCP Transport
>
>A DNS responder MAY behave different
Support adoption
this is actually a needed document, due to the fact that many "high value
zones" want to use multiple vendors.
Olafur
On Fri, Jul 6, 2018 at 8:26 PM, Tim Wicinski wrote:
>
> We've had some interest in moving this document forward, and the chairs
> wanted to kick off this
Hi
i read this document over with fresh eyes and tried to ignore any history.
Summary: Publication considered harmful
Reasons: This document calls itself "Security Considerations" but in
reality all it is covering is "Publication considerations by Authority"
the document does not cover at all the
Yes
On Tue, Jul 10, 2018 at 9:22 PM, Mark Nottingham wrote:
>
>
> > On 11 Jul 2018, at 3:55 am, Joe Abley wrote:
> >
> > On Jul 10, 2018, at 18:02, Adam Roach wrote:
> >
> >> In large part because DNS provides "a richer scheme that accommodates
> address families and multiple addresses with p
It is a random label on the left that some random resolvers may generate
answers for,
thus it is not SUN (i.e. answer B)
Olafur
On Mon, May 14, 2018 at 2:10 PM, Warren Kumari wrote:
> Dear DNSOP,
>
> The KSK-Sentinel document (
> https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-12
Mike,
This is a domain extortion attempt, they want you to buy the domain at
inflated price
https://security.stackexchange.com/questions/56290/is-this-domain-registration-service-email-a-scam#56304
Olafur
On Sun, Mar 25, 2018 at 11:04 PM, Michael StJohns
wrote:
> Apologies for dumping this he
On Thu, Mar 22, 2018 at 1:00 PM, Shumon Huque wrote:
> On Thu, Mar 22, 2018 at 12:50 PM, Tony Finch wrote:
>
>> Olafur Gudmundsson wrote:
>> >
>> > I think only Model #1 makes sense, i.e Zone apex DNSKEY/CDNSKEY/CDS
>> > RRset's are signed by zone publisher but rest signed by operator on the
>>
On Tue, Mar 13, 2018 at 11:16 AM, Joe Abley
wrote:
> On 12 Mar 2018, at 11:58, Roland Bracewell Shoemaker <
> rol...@letsencrypt.org> wrote:
>
> > After a number of discussions I’m interested in returning to the
> original concept as it simplifies a number of use cases that this document
> is int
On Thu, Jan 11, 2018 at 11:26 AM, 神明達哉 wrote:
> At Wed, 10 Jan 2018 17:05:00 -0800,
> Ólafur Guðmundsson wrote:
>
> > >That is, it answers as if it is authoritative and the DS record does
> > >not exist. DS-aware recursive nameservers will query the parent
&g
On Fri, Jan 5, 2018 at 10:27 AM, 神明達哉 wrote:
> At Thu, 4 Jan 2018 08:12:26 +1100,
> Mark Andrews wrote:
>
> > The reply also has to work for STD13 clients which already know
> > about the child zone. The NODATA response is the correct one despite
> > it requiring more work for a DNSSEC client.
>
On Fri, Dec 1, 2017 at 5:02 PM, Wessels, Duane
wrote:
>
> > On Dec 1, 2017, at 8:38 AM, Ólafur Guðmundsson
> wrote:
> >
> > I strongly disagree with your "terminology", TTL is a hint about maximum
> caching period, not a demand or a contract.
>
> You
I strongly disagree with your "terminology", TTL is a hint about maximum
caching period, not a demand or a contract.
A resolver can at any time for any reason discard cached entries.
Many Authoritative operators have "unreasonable" TTL's like less than 10
seconds or multiple days and I see no reaso
On Thu, Nov 9, 2017 at 12:01 AM, Paul Wouters wrote:
> On Wed, 8 Nov 2017, Edward Lewis wrote:
>
> This is why the guidance in "Protocol Modifications for the DNS Security
>> Extensions" leads to "any" chain. "Clarifications and Implementation Notes
>> for DNS Security (DNSSEC)" opens the possibi
On Tue, Oct 31, 2017 at 11:30 AM, Paul Wouters wrote:
>
>
> > On Oct 31, 2017, at 22:25, Ólafur Guðmundsson
> wrote:
> >
> >
> > There are three ways to treat this case:
> > Any-TruestedKey-works
> > ConfiguredKey-trumps-DS
> > DS-trumps-conf
There are three ways to treat this case:
Any-TruestedKey-works
ConfiguredKey-trumps-DS
DS-trumps-configuredKey
I think the Last one is the "most" correct from an operational expectation,
but the first one is least likely to run into errors,
But I suspect the middle one is implemented
Olafur
On
This was the original proposal,
the drawback is that resolvers to not cache the answer, and to make things
worse they ask ALL NS addresses for listed domain
thus it acts as a DDoS against the domain in question.
Olafur
On Mon, Aug 7, 2017 at 7:14 AM, Ray Bellis wrote:
> Having looked at this a
On Thu, Jul 20, 2017 at 10:45 AM, Shumon Huque wrote:
> On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson <
> ola...@cloudflare.com> wrote:
>>
>>
>> I disagree, if a zone operator selects "less-than" common algorithm they
>> do that at their own
On Tue, Jul 11, 2017 at 12:16 AM, Shumon Huque wrote:
> On Mon, Jul 10, 2017 at 5:01 PM, Ólafur Guðmundsson > wrote:
>
>> Shumon,
>>
>> In section 5 your draft says:
>>
>>If an Authoritative Server has no algorithms in common with the
>>Pr
Shumon,
In section 5 your draft says:
If an Authoritative Server has no algorithms in common with the
Preferred Algorithms list in the incoming query, it MUST send back a
SERVFAIL response (Response Code 2). This response MUST contain the
list of algorithms supported by the server in
The errata is correct.
Ólafur
sent from phone
On Jun 23, 2017 11:54, "RFC Errata System"
wrote:
> The following errata report has been submitted for RFC8078,
> "Managing DS Records from the Parent via CDS/CDNSKEY".
>
> --
> You may review the report below an
Anthony,
Good writeup
Section 3.4 is in conflict with Refuse-Any draft (in WGLC)
IMHO there is no need to say that there is special processing for ANY
query; so drop section 3.4
Olafur
On Wed, Mar 29, 2017 at 9:51 AM, Anthony Eden
wrote:
> After attending the dnsop meeting on Monday I decid
I will be happy to take it over
Olafur
On Tue, Mar 28, 2017 at 12:03 PM, Stephane Bortzmeyer <
bortzmeyer+i...@nic.fr> wrote:
> On Sun, Mar 26, 2017 at 11:36:08AM -0700,
> RFC Errata System wrote
> a message of 42 lines which said:
>
> > The following errata report has been verified for RFC8
On Mon, Feb 13, 2017 at 9:50 AM, Richard Gibson wrote:
> On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds wrote:
>
>> You think this would actually provide any sort of useful information? No
>> operator would understand what "MBZ: 0x" means without re-training,
>> and if you're re-training o
Thank you for your comments
Q: why do you think it is useful to complicate things with a EDNS0 flag ?
Olafur
On Thu, Feb 9, 2017 at 8:47 PM, Richard Gibson wrote:
> With full realization that this is coming very late in the game, we had a
> great deal of internal conversation within Dyn abou
John,
Thanks for the review
you are spot on, I should not edit while watching a soccer game :-(
I will post an updated version in the next few days.
how about for section 4.1:
I was trying to cover the case where the RRSET selected has Multiple
RRSIG's not
About 4.2.
Implementation may choose t
This version addresses all the comments that the chair's determined needed
addressing.
Olafur
On Wed, Feb 8, 2017 at 9:56 PM, wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations of the IET
Yes I agree,
Push a new version if Tim agrees ?
Olafur
On Tue, Jan 10, 2017 at 12:53 PM, Paul Wouters wrote:
> On Tue, 10 Jan 2017, Matthijs Mekking wrote:
>
> I personally think the simplification of using all zero's is good. If
>>> someone accidentally changes the wrong number in the DS rec
On Wed, Jan 4, 2017 at 12:33 PM, Nicholas Weaver
wrote:
> Any system which prevents zone enumeration requires online signing,
> https://www.cs.bu.edu/~goldbe/papers/nsec5faq.html
>
> But NSEC5 is almost certainly not going to be adopted, simply because of
> the partial deployment problem.
>
> NSE
Those numbers are not allocated they are just an artifact of bad design
from the 199x's
Olafur
On Fri, Dec 30, 2016 at 6:00 AM, A. Schulze wrote:
> Hello,
>
> I'm searching for a reference (IANA?) that define the DNSSEC hash
> algorithm hmac-sha256
> has assigned the number 159
> ( see http://
On Wed, Nov 30, 2016 at 10:43 AM, Matt Larson wrote:
>
> > On Nov 29, 2016, at 8:31 AM, Olafur Gudmundsson wrote:
> >
> > IMHO the device should have two sources of truth for DNSSEC root TA
> > a) DNS via RFC5011
> > b) Secure Software update from the vendor
> >
> > If both fail then operator sh
ndřej Surý -- Technical Fellow
>
> CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC
> Milesovska 5, 130 00 Praha 3, Czech Republic
> mailto:ondrej.s...@nic.cz https://nic.cz/
>
>
> - O
Dear colleagues
This version addresses all the outstanding requests for changes.
The editors believe this version is ready for WGLC.
thanks
Olafur
On Wed, Nov 16, 2016 at 2:44 PM, wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a wo
Registrars/IANA/Registries/Resellers ==> Parents or Parental Agents
Olafur
On Mon, Nov 7, 2016 at 7:22 AM, Ondřej Surý wrote:
> And you can replace "registrars" with "IANA" and your
> whole paragraph would still be correct. This is another
> area that hinders deployment of "new" (ehm, ehm) a
I will be happy to do that, stay tuned as I need to create a special
signer for it :-)
Olafur
On Sun, Oct 16, 2016 at 4:16 AM, Mikael Abrahamsson
wrote:
> On Sat, 15 Oct 2016, Ólafur Guðmundsson wrote:
>
> I have domains signed by all combinations of signing algorithms and DS
>
I have domains signed by all combinations of signing algorithms and DS
digests as well as Nsec variants
Ds-n.alg-m-nsec.dnssec-test.org
Replace n with 1..4
M with 1..14
Nsec is one of Nsec nsec3 none
Ólafur
sent from phone
On Oct 15, 2016 17:29, "Geoff Huston" wrote:
>
> > On 16 Oct. 2016, at
On Mon, Sep 26, 2016 at 8:33 AM, Peter van Dijk wrote:
> Hello,
>
> On 23 Sep 2016, at 10:22, Stephane Bortzmeyer wrote:
>
> On Tue, Sep 20, 2016 at 06:13:50PM +0200,
>> Stephane Bortzmeyer wrote
>> a message of 68 lines which said:
>>
>> This issue was spotted by Peter van Dijk. It is about
>
This version contains minor text and structure improvements suggested by
TimW.
Editors think the document is ready for WGLC
Olafur
On Mon, Jul 25, 2016 at 6:38 AM, wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Do
One DS +DNSKEY is sufficient, others are ignored as they can be for past or
future keys.
The only exception is when the DS records are for multiple algorithms some
implementations demand that all algorithms are working
Olafur
On Thu, Jul 14, 2016 at 12:20 PM, Einar Bjarni Halldórsson
wrote:
>
Dear colleagues
This version addresses all comments received during the WGLC,
The main changes are clarifications requested by reviewers.
In addition some reordering was done to fit better with the model that
operations are "Introduction Maintainance Deletion"
In the IANA section there is a new pa
On Tue, Apr 26, 2016 at 5:13 AM, Matthijs Mekking
wrote:
> All,
>
> Matthijs thanks for the review
sorry for the delay in response.
> I have read it and I like it. Still there are I think some things that
> need to be addressed:
>
> - On enabling DNSSEC via CDS/CDNSKEY: most of the policies ass
Dear colleagues,
a new version of the document has been posted that fixes few minor
grammatical and spelling errors.
this is version 02
URL:
https://www.ietf.org/internet-drafts/draft-ietf-dnsop-maintain-ds-02.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
Htmlized:
On Fri, Mar 25, 2016 at 10:51 PM, John Levine wrote:
> >As I think many here know, I am not of the get-off-my-lawn persuasion
> >for DNS innovations. I don't think it's a bad idea in principle. I'm
> >just aware that we have this long history, and that history was based
> >on a certain kind of
On Tue, Mar 22, 2016 at 6:11 PM, Mark Andrews wrote:
>
> In message <2016030345.29993...@pallas.home.time-travellers.org>,
> Shane Kerr writes:
> > Maybe we just need a new RTYPE. It would be awesome if CloudFlare
> > killed ANY and then gave us ANYA ("any address"). ;)
>
> You would then nee
On Sun, Mar 20, 2016 at 2:55 PM, Paul Hoffman wrote:
> On 20 Mar 2016, at 10:55, Ólafur Guðmundsson wrote:
>
> On Sat, Mar 19, 2016 at 4:04 PM, Paul Hoffman
>> wrote:
>>
>> [[ Dropping CURDLE because these discussions should only be in one WG ]]
>>>
>&g
On Sat, Mar 19, 2016 at 4:04 PM, Paul Hoffman wrote:
> [[ Dropping CURDLE because these discussions should only be in one WG ]]
>
>ECDSAP256SHA256 and ECDSAP384SHA384 provide more strength for
>signature size than RSASHA256 and RSASHA512 variants. It is expected
>to be raised to MUST
https://www.iana.org/assignments/tsig-algorithm-names/tsig-algorithm-names.xhtml
Olafur
On Tue, Mar 8, 2016 at 8:48 AM, Mukund Sivaraman wrote:
> Hi all
>
> There doesn't seem to be a registry of TSIG algorithm identifiers (at
> least I am not able to find it):
>
> https://tools.ietf.org/html/
On Wed, Mar 2, 2016 at 9:10 AM, Shane Kerr
wrote:
> Evan,
>
> I think that moving Fujiwara's fuller proposal forward will likely take
> an extra year and don't see any conflict with the cheese shop approach
> really. However since the cheese shop won't likely result in any
> running code, I also
On Wed, Mar 2, 2016 at 6:49 AM, Evan Hunt wrote:
> On Wed, Mar 02, 2016 at 08:06:39AM +1100, Mark Andrews wrote:
> > ANC does not work for zones using OPTOUT. This is just about all
> > TLDs and similar zones.
>
> To be pedantic, it doesn't work for optout ranges. I don't actually know
> offhand
On Mon, Feb 29, 2016 at 4:03 PM, Warren Kumari wrote:
>
>
> On Mon, Feb 29, 2016 at 10:04 AM Shane Kerr
> wrote:
>
>> Ed,
>>
>> At 2016-02-29 14:34:39 +
>> Edward Lewis wrote:
>> > I don't think I was clear - this is only about the DNS protocol. This
>> > document proposes that the DNS pro
On Mon, Feb 22, 2016 at 9:21 PM, George Michaelson wrote:
>
>
> On Tue, Feb 23, 2016 at 3:05 PM, Paul Wouters wrote:
>>
>> Face to face time is rare. It also does not include everyone that's on
>> the list. So where possible, discussion on the lists is always preferred.
>
>
> A good bar. A high
On Sun, Feb 7, 2016 at 2:16 PM, Tony Finch wrote:
> Another question:
>
> In order to minimize responses even further, I have made my code omit or
> include signature records depending on whether DO=0 or DO=1. That is, and
> ANY query with DO=0 gets one arbitrary unsigned RRset in response, and a
Jakob, Patrik
thanks for writing this up, a great start.
On first read this document seems to be duplicating what is in
https://tools.ietf.org/html/rfc1912
It is hard to see what is new and what is the same.
There are number of assumptions in the current draft, that only apply when
the DNS conten
On Fri, Feb 5, 2016 at 10:10 PM, Tony Finch wrote:
> Last weekend one of our authoritative name servers
> (authdns1.csx.cam.ac.uk) suffered a series of DoS attacks which made it
> rather unhappy. Over the last week I have developed a patch for BIND to
> implement draft-ietf-dnsop-refuse-any which
Just submitted the first working group draft, only change from prior
version
a) added what working group it is in
b) updated reference for Negative Trust anchor to be the RFC
You will see it as soon as one of the chairs approves the document.
New version addressing comments we have received will b
Stephen,
Sorry for being so blunt below.
The document totally content free as to why this makes any sense in an
operational context.
DNSSEC algorithms should not be given out lightly as there is a significant
COST to deploy support for each additional algorithm.
While I strongly support having b
The reasoning is in https://tools.ietf.org/html/rfc3597
On Tue, Dec 8, 2015 at 10:09 AM, Paul Wouters wrote:
>
> Hi,
>
> Section 6.2 of 4034 talks about canonicalization of the RR Form
>
> Item 3 states:
>
> 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
>HINFO, MI
On Mon, Nov 9, 2015 at 12:52 PM, Evan Hunt wrote:
> On Mon, Nov 09, 2015 at 04:55:24PM +, Tony Finch wrote:
> > With the current DNS protocol, a stub resolver can get all the records it
> > needs to validate a response in 1RTT, by sending multiple concurrent
> > queries for all the possible d
On Tue, Oct 13, 2015 at 11:00 PM, Evan Hunt wrote:
> On Tue, Oct 13, 2015 at 10:10:39PM +0100, Ólafur Gušmundsson wrote:
>
>
> > Is reference to RFC4770 security considerations good enough ?
>
> Sorry, which RFC? "vCard Extentions for Instant Messaging" doesn't
> seem likely to be what you mean
On Tue, Oct 13, 2015 at 7:28 PM, Evan Hunt wrote:
> Hi Joe,
>
> I think you need some more text in the description of pick-one-rrset,
> something like:
>
>
> A DNS responder which receives an ANY query MAY decline to provide
> a complete response, and MAY instead choose to return only one of
On Sun, Oct 4, 2015 at 7:32 AM, Dave Lawrence wrote:
> A couple of quick observations:
>
> * The draft says that the answer in a signed zone MAY be unsigned.
> Since this will ultimately cause a SERVFAIL for validating
> resolvers, it is not really acceptable.
>
You and Evan,
are right we w
On Wed, Sep 30, 2015 at 10:08 PM, Evan Hunt wrote:
> On Wed, Sep 30, 2015 at 11:28:45PM -0400, Joe Abley wrote:
> > 1. Return an unsigned response. This will be marked as bogus, and
> > trigger a QTYPE=HINFO re-query that will either return an actual signed
> > HINFO from the zone or a signed pro
On Mon, Sep 28, 2015 at 9:53 PM, Mukund Sivaraman wrote:
> Hi Paul
>
> On Mon, Sep 28, 2015 at 02:36:25PM -0400, Paul Wouters wrote:
> > On Mon, 28 Sep 2015, Paul Vixie wrote:
> >
> > >those things should also be done in the short term.
> > >
> > >but it's the internet. it'll outlive us all. we o
FYI,
this is latest incarnation of of how to give out minimal answer to ANY
query without breaking anything and being friendly to resolvers.
Comments,
Olafur
-- Forwarded message --
From:
Date: Wed, Sep 30, 2015 at 12:04 PM
Subject: New Version Notification for draft-jabley-dnsop
On Tue, Aug 25, 2015 at 11:02 PM, Shane Kerr
wrote:
> Paul,
>
> On Tue, 25 Aug 2015 18:15:02 -0400 (EDT)
> Paul Wouters wrote:
>
> > On Tue, 25 Aug 2015, Ólafur Guðmundsson wrote:
> >
> > > This is a proposed update the CDS/CDNSKEY processing to address the
This is a proposed update the CDS/CDNSKEY processing to address the
omission in RFC7344.
Comment please,
Olafur
Ps: I'm using a new markup tool to write the ID thus any errors in format
are my fault.
https://github.com/miekg/mmark
-- Forwarded message --
From:
Date: Tue, Aug 25
ppers/namedroppers.2008/msg01131.html
http://psg.com/lists/namedroppers/namedroppers.2008/msg01677.html
thanks
Olafur
Date: Wed, 12 Nov 2008 10:26:08 -0500
To: [EMAIL PROTECTED]
From: Ólafur Guðmundsson /DNSEXT
chair <[EMAIL PROTECTED]>
Subject: Re: [dnsext] Re: Time-line
84 matches
Mail list logo
