On 2022-11-25 12:26 -05, Daniel Migault wrote:
> On Wed, Nov 23, 2022 at 10:29 AM Vladimír Čunát
> wrote:
>> I am surprised you would not recommend RFC 5011
>>
>> 5011 needs persistent state, a thing that resolvers/validators often don't
>> need at all otherwise (cache is safe to delete). 5011
I might not be caffeinated enough yet, but I think the next domain name
in section 5 should be \000.ent1.example.net:
ent1.example.net. 3600 IN NSEC \000.ent1.example.net. RRSIG NSEC ENT
In section 6, calling getaddrinfo() return values exit codes is a bit
odd, maybe this will do?
On 2023-03-28 05:51 -07, Paul Vixie wrote:
> see inline.
>
> Viktor Dukhovni wrote on 2023-03-27 18:00:
>> [ Multi-response to four upthread messages. ]
>> ---
>> ...
>> A possibly inconvenient question, just to make sure we're not
>> ignoring
>> the obvious sceptical position:
>> * How compel
On 2023-06-07 13:08 -04, Tim Wicinski wrote:
> Just a reminder we're looking for any feedback on continuing work on this
> document. The Chairs/OverLord Warren feel significant work on this
> document is needed, but that may not be relevant.
The document seems to have a rather pessimistic view o
I gave this a once-over.
1. Introduction
> Generally only one temporary DNS record is sufficient for
> proving domain ownership, although sometimes the DNS record must be
> kept in the zone to prove continued ownership of the domain.
I understand what it's trying to say, but I think "a" instead
On 2023-07-17 12:40 -04, "John Levine" wrote:
> It appears that Florian Obser said:
>>I gave this a once-over.
>>3. Common Pitfalls
>>> If the size of the response is large enough that it does not fit into
>>> a single DNS UDP packet (UDP being the
Sorry for being very late.
I find the usage of FLAG- weird.
I think FLAG-LABELS should just be LABELS or LABELCOUNT.
What really tripped me was FLAG-NUMBER. It is introduced in section 2,
without any indication what it does. I think it should be called TYPE, a
flag is a thing that's "on" or "off
Sorry for being very late, I was swamped with other stuff
| 4.2. Completeness of the Response
|
| At the time this document is published, there are 13 root server
| operators operating a total of more than 1500 root server instances.
There are only *12* operators, operating 13 letters. a-roo
On 2024-03-17 20:12 -07, internet-dra...@ietf.org wrote:
> Internet-Draft draft-ietf-dnsop-ns-revalidation-06.txt is now available. It is
| 7. Security Considerations
| [...]
| In case of non DNSSEC validating
| resolvers, an attacker controlling a rogue name server for the root
| has potentially
On 2024-03-18 10:33 +01, Philip Homburg wrote:
> In your letter dated Mon, 18 Mar 2024 08:01:38 +0100 you wrote:
>>On 2024-03-17 20:12 -07, internet-dra...@ietf.org wrote:
>>> Internet-Draft draft-ietf-dnsop-ns-revalidation-06.txt is now available. It
>>is
>>
>>| 7. Security Considerations
>>| [
Take note of the intended status. I thought that to be... ambitious ;)
--
In my defence, I have been left unsupervised.
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
I did the dnsdir early review of -00, all my nits have been addressed.
As a root server operator I don't see anything wrong with the document,
not that it would effect me...
I think it's good to go to be published as an RFC.
--
In my defence, I have been left unsupervised.
__
I finally got around to use a more sensible setting for my personal
domains, i.e. the recommended one.
I did have to refresh my memory on how NSEC3PARAM works by glancing at
RFC 5155 though. Maybe something like this at the end of
"3. Best-practice for zone publishers" would be helpful:
| Since t
On 2024-10-15 07:49 -07, Wes Hardaker wrote:
> Paul Hoffman writes:
>
>> In specific, "Use for DNSSSEC Signing" and "Use for DNSSSEC
>> Delegation" do not make sense if there is more than one "MUST" in that
>> column. You cannot use two algorithms to sign or delegate at the same
>> time.
>
> Than
ree one could deduce that one is
talking to the "wrong" resolver. But that's probably not very useful and
the risk people doing stupid things with it is probably too high.
>
> Thanks,
> Tommy
>
>> -Original Message-
>> From: Florian Obser
>> Sen
On 2024-09-09 17:51 -05, Nick Buraglio wrote:
> dnsop folks,
>
> Based on some conversations and discussions at the end of the second
> session at 120, several of us worked out a draft to address what we believe
> are some notable details in RFC7050. This draft was just submitted to the
> datatrac
On 2024-10-24 09:28 +11, Jen Linkova wrote:
> On Tue, Oct 22, 2024 at 1:42 AM Florian Obser wrote:
>> It occurred to me that a validating stub resolver still needs to know if
>> its upstream is messing with DNS. With RFC9606 we can just ask the
>> resolver what it's d
On 2025-02-06 08:56 +01, Philip Homburg wrote:
>>What we all keep ignoring is that .internal DOES NOT WORK WITH
>>BRING YOUR OWN DEVICE scenarios Reverse for RFC1918 addresses
>>work with BYOD because we have public AS112 servers that serve
>>UNSIGNED reverse zones. This breaks t
Reviewer: Florian Obser
Review result: Ready with Issues
I have been selected as the DNS Directorate reviewer for this draft. The
DNS Directorate seeks to review all DNS or DNS-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the
19 matches
Mail list logo
