I see a message on dnsop from you proposing a bunch of things
including "rationalizing" names, and comments from Andrew and Peter
saying they like that approach.
I am not finding any message from me with that word in it, so I've no idea
what you are referring to.
Perhaps the link you sent
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 WG of the IETF.
Title : A Root Key Trust Anchor Sentinel for DNSSEC
Authors : Geoff Huston
Joa
On Fri, Mar 23, 2018 at 5:53 PM, Frederico A C Neves wrote:
> On Fri, Mar 23, 2018 at 01:22:42PM -0400, Bob Harold wrote:
>> On Fri, Mar 23, 2018 at 1:19 PM, Paul Hoffman wrote:
>>
>> > +1 to the title “A Root Key Trust Anchor Sentinel for DNSSEC”.
>> >
>> > +1 to option #2 with the spelling corr
Dear DNSOP,
I'd like to share some pointers from the working group that governs the
BGP protocol, IDR, on requiring implementations before drafts can
advance towards RFC publication. Raising the bar for publication will
take weight off the camel's back.
The IDR policy and rationale is outlined he
On Fri, Mar 23, 2018 at 06:32:07PM +, Ondřej Surý wrote:
> What’s so wrong of using TYPExxx for these if you absolutely need them to run
> the ancient technology while at the same time running the latest version of
> BIND (or your favorite DNS server)?
>
> Your argument feels like strawman t
On Mar 24, 2018, at 13:49, Jared Mauch wrote:
>isc/bind can and perhaps should implement logging for these
> rrtypes that say they may be going away so folks can see the impact.
I'm actually surprised to see that support for rarely-used RRTypes is
really upsetting the camel.
A combinatorial
Finally catching up.
>For any use of an underscore first-level name, that also uses a
>second-level name, the authority over that second-level belongs entirely
>and solely to that first-level name.
>
>..._my-second._firsta.example
>
>and
>
>..._my-second._firstb.example
>
>have no confli
> On 24 Mar 2018, at 13:48, Joe Abley wrote:
>
> But I think brushing the grains RRType parsing dust off the
> camel is not going to do much for its posture.
+1.
IMO there’s no need to do this in the protocol unless there is convincing proof
that nobody anywhere is using a now-obsolete RRtyp
Joe,
it’s actually not the complexity in BIND (although I view everything as extra
complexity), it’s the interop for new players that need to implement every
piece of rusty junk that's in the protocol to be interoperable.
While it seems to be attractive to keep the existing open-source tetrapol
Hi everyone,
[tl;dr, check out https://powerdns.org/dns-camel/ ]
As a first step in attempting to not only whine about a glut of DNS
standards, I've made an easy to update viewer of all DNS relevant standards.
The good news is, if we filter out obsoleted, historical, informational and
BCP docume
On 24 March 2018 at 12:51, bert hubert wrote:
> Hi everyone,
>
> [tl;dr, check out https://powerdns.org/dns-camel/ ]
>
> As a first step in attempting to not only whine about a glut of DNS
> standards, I've made an easy to update viewer of all DNS relevant
> standards.
>
> The good news is, if we
On Sat, Mar 24, 2018 at 02:58:55PM +, Jim Reid wrote:
> IMO there's no need to do this in the protocol unless there is convincing
> proof that nobody anywhere is using a now-obsolete RRtype. An RFC saying
> a server could return FORMERR (or whatever) when it gets a query for one
> of these dea
On 24 March 2018 at 12:56, Matthew Pounsett wrote:
> I'd suggest you should also filter out ops documents like RFC6781, since
> those serve to clear up the complexity rather than contribute to it. I'll
> send a pull request in a bit with the ones I've spotted.
>
>
I went to go dig into this and
On 24 March 2018 at 09:48, Joe Abley wrote:
> But I think brushing the grains RRType parsing dust off the
> camel is not going to do much for its posture.
>
> +1
Speaking from experience, having spent a few dozen hours so far on some
client code, the code necessary to implement an additional RRT
> It might be a different story if one of those zombie RRtypes required
> additional processing. None spring to mind though.
But (most of) those I picked actually *DO*:
a) compression is allowed, so compliant and non-compliant servers can’t speak
together, because non-compliant will just store
Hi Ondrej
On Sat, Mar 24, 2018 at 09:20:06PM +0100, Ondřej Surý wrote:
> > It might be a different story if one of those zombie RRtypes required
> > additional processing. None spring to mind though.
>
> But (most of) those I picked actually *DO*:
In the case of RR types, "additional processing
Thanks Dick, this is very helpful suggestion and I’ll use it.
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 24 Mar 2018, at 00:06, Dick Franks wrote:
>
>
> On 23 March 2018 at 12:11, Ondřej Surý wrote:
>
> this is a first attempt to start reducing the load on DNS Implementors and
> actually rem
Hi,
I’ll conflate more emails into one, as it seems there is a repeating pattern. I
would also prefer if somebody
> On 24 Mar 2018, at 15:58, Jim Reid wrote:
>
> Obsoleted RRtypes shouldn’t overload the camel enough to matter. It might be
> a different story if one of those zombie RRtypes req
> On 24 Mar 2018, at 22:55, Mukund Sivaraman wrote:
>
> Hi Ondrej
>
> On Sat, Mar 24, 2018 at 09:20:06PM +0100, Ondřej Surý wrote:
>>> It might be a different story if one of those zombie RRtypes required
>>> additional processing. None spring to mind though.
>>
>> But (most of) those I picked
19 matches
Mail list logo
