(no hats on)
I've read this, and I agree it should move forward.
Should there be a reference to RFC8499 in here as well?
(with chairs hat on)
Mr Finch made some editorial nits that I concur with. I also ran the Nits
tool and found several outdated references,
among other things. I've
The following errata report has been verified for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6551
The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6551
It appears that Brian Dickson said:
>Private-use TLDs will fail DNSSEC validation which uses the IANA DNSSEC
>Root Trust Anchor.
>Organizations using names beneath such private-use TLDs while operating
>validating recursive resolvers or validating stub resolvers need to also
>manage trust
On Sun, Apr 18, 2021 at 4:17 PM Suzanne Woolf
wrote:
> Dear colleagues,
>
>
> This message starts the Working Group Last Call
> for draft-ietf-dnsop-tcp-requirements (
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/)
>
> Since this draft has not been recently discussed
On Mon, Apr 19, 2021 at 9:34 AM Paul Hoffman wrote:
> On Apr 19, 2021, at 7:17 AM, Andrew McConachie wrote:
> >
> >
> >
> > On 16 Apr 2021, at 17:18, Paul Hoffman wrote:
> >
> >> On Apr 16, 2021, at 5:31 AM, Andrew McConachie
> wrote:
> >>
> >>> If I understand section 4.3 correctly, DNSSEC
On 19 Apr 2021, at 12:40, Peter van Dijk wrote:
> This note on statelessness is good, but I don't think it should be tied to
> IPv6. Packets get lost in IPv4 too, especially when they are big, and even if
> such evens trigger a report in the form of an ICMP message, the same
> lack-of-state
It appears that Paul Hoffman said:
>That's correct, as it would be for any private-use TLD. In fact, it's not just
>about validating stubs: an organization wanting to use a
>private-use TLD cannot have validating stub resolvers or validating recursive
>resolvers anywhere in the organization.
On Mon, 2021-04-19 at 07:31 -0400, Joe Abley wrote:
> NEW:
>
>For IPv4-connected hosts, the MTU is often the Ethernet payload
>size of 1500 bytes. This means that the largest unfragmented
>UDP DNS message that can be sent over IPv4 is likely 1472 bytes,
>although tunnel
> This message starts the Working Group Last Call for
> draft-ietf-dnsop-tcp-requirements
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/)
This is a good document.
One comment here:
The FreeBSD, OpenBSD, and NetBSD operating systems have an "accept
filter"
On Apr 19, 2021, at 7:17 AM, Andrew McConachie wrote:
>
>
>
> On 16 Apr 2021, at 17:18, Paul Hoffman wrote:
>
>> On Apr 16, 2021, at 5:31 AM, Andrew McConachie wrote:
>>
>>> If I understand section 4.3 correctly, DNSSEC validating stub resolvers
>>> SHOULD NOT resolve these names. Is that
On 19/04/2021 17:08, Lanlan Pan wrote:
>
>
> Ray Bellis mailto:r...@bellis.me.uk>> 于2021年4月16日
> 周五 下午4:19写道：
>
> Many DNS proxies / ALGs don't inspect the packet contents at all, so a
> stronger generic requirement was not feasible.
>
>
> depends on use case ?
> enterprise dns
Ray Bellis 于2021年4月16日周五 下午4:19写道：
>
>
> On 14/04/2021 10:19, Stephane Bortzmeyer wrote:
>
> > Regarding dnsop work, the same report suggests to modify RFC 5625 "DNS
> > Proxy Implementation Guidelines" to replace the MAY in section 6.3 by
> > a MUST. I think that the reason there is currently a
Suzanne Woolf wrote:
>
> This message starts the Working Group Last Call for
> draft-ietf-dnsop-tcp-requirements
I have read the draft and I am keen to see it published. Just the other
day I was having a discussion about whether TCP support is really needed,
and I wanted something stronger than
On 16 Apr 2021, at 17:18, Paul Hoffman wrote:
On Apr 16, 2021, at 5:31 AM, Andrew McConachie
wrote:
If I understand section 4.3 correctly, DNSSEC validating stub
resolvers SHOULD NOT resolve these names. Is that the intention of
Section 4.3?
No, definitely not. The text says:
3.
On 18 Apr 2021, at 19:17, Suzanne Woolf wrote:
> We’d like to advance this but it needs some active support, so we need to
> hear from folks who have found it useful, especially implementers.
I didn't mention explicitly before, sorry, but I think this is a good document,
it's useful and it
Hi John,
On 19 Apr 2021, at 07:57, John Kristoff wrote:
> On Mon, 19 Apr 2021 07:31:49 -0400
> Joe Abley wrote:
>
>> NEW:
>>
>> The specification of the DNS allows both UDP and TCP to be used
>> as transport protocols for exchanging unencrypted DNS messages.
>> However, for various
> -Original Message-
> From: DNSOP On Behalf Of Paul Hoffman
> Sent: Thursday, April 15, 2021 7:15 PM
> To: DNSOP Working Group
> Subject: [EXTERNAL] [DNSOP] New version of draft-ietf-dnsop-rfc7816bis
> after WG last call
>
> Greetings again. We have posted a very delayed version
On Mon, 19 Apr 2021 07:31:49 -0400
Joe Abley wrote:
> NEW:
>
>The specification of the DNS allows both UDP and TCP to be used
>as transport protocols for exchanging unencrypted DNS messages.
>However, for various reasons, the availability of TCP transport
>has sometimes been
Hi Suz,
On 18 Apr 2021, at 19:17, Suzanne Woolf wrote:
> This message starts the Working Group Last Call for
> draft-ietf-dnsop-tcp-requirements
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/
>
20 matches
Mail list logo
