In article <247af5e0-8214-4312-b362-431c56e4f...@isc.org>,
Mark Andrews wrote:
>> Uh, what? In the past 30 years we've assigned under 100 rrtypes. If that
>> rate increases by an order of
>magnitude, we still have a thousand years of them. Sure we don't know exactly
>what the future will bri
On Mon, Sep 10, 2018 at 9: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 cut
> On 11 Sep 2018, at 8:51 am, John R Levine wrote:
>
> On Tue, 11 Sep 2018, Mark Andrews wrote:
>>> Since the type code is a 16-bit field, if we allocate a new type every
>>> week, it'll take over a thousand years to run out. I think this is one we
>>> can safely ignore.
>>
>> If we end up wi
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 cut this
introductory paragraph, however.)
Please refer to ht
On Sep 10, 2018, at 18:51, John R Levine wrote:
> Classes were a mistake. We should deprecate every class except IN, perhaps
> keeping the one special case for CH server.bind.
FWIW,
[monster:~]% strings $(which named) | egrep 'zone .* chaos '
zone "version.bind" chaos {
zone "
On Tue, 11 Sep 2018, Mark Andrews wrote:
Since the type code is a 16-bit field, if we allocate a new type every
week, it'll take over a thousand years to run out. I think this is one we
can safely ignore.
If we end up with a type per protocol because people want wildcards to work
we will burn
Hi,
> On Sep 10, 2018, at 12:48 PM, Paul Vixie wrote:
>
> Andrew Sullivan wrote:
>> ...
>>
>> I agree with Paul Vixie that classes were never defined well enough to
>> be made to work properly, at least at Internet scale.
>
> this thread has further cemented my prejudice against CLASS. however
DNSOP/Paul:
I am working on an application that will have DNS filters or
translators in the config file. My current design uses Paul Hoffman's RFC 8427
JSON DNS format to allow the filters to make packet alterations. As an example,
think about an older printer service with SRV/TXT recor
> On 11 Sep 2018, at 7:39 am, John Levine wrote:
>
> In article <20180910165922.ga31...@isc.org> you write:
>> On Mon, Sep 10, 2018 at 09:48:05AM -0700, Paul Vixie wrote:
>>> Andrew Sullivan wrote:
I agree with Paul Vixie that classes were never defined well enough to
be made to work
> On Sep 10, 2018, at 1:13 PM, Lee Howard wrote:
>
>
>
> On 09/06/2018 03:14 AM, Shane Kerr wrote:
>> All,
>>
>> On 2018-09-05 20:45, internet-dra...@ietf.org wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the
In article <20180910165922.ga31...@isc.org> you write:
>On Mon, Sep 10, 2018 at 09:48:05AM -0700, Paul Vixie wrote:
>> Andrew Sullivan wrote:
>> > I agree with Paul Vixie that classes were never defined well enough to
>> > be made to work properly, at least at Internet scale.
Agreed. Since it's a
And part of not making that too difficult is making new types IN specific by
default. You need to argue for class agnostic.
You can always replicate a class specific type in a new class. You can’t go
from class agnostic to class specific.
--
Mark Andrews
> On 11 Sep 2018, at 02:59, Evan Hunt
Firstly you can’t avoid dealing with time if you want validators to always
successfully validate answers from a signed zone as there are coaches involved
and the DNS is loosely coherent. The DNS isn’t HTTPS, you aren’t always
directly dealing with the authoritative server or a proxy like you a
Generally, CRLs work reasonably well for revoking intermediate CAs and
leaf certificates, not so well for dealing with trust anchors. CRLs
work by the parent signing the revocation (and by being able to re-issue
new certificates). Root certs/trust anchors by definition do not have
parents.
Hi all,
My question is that instead of messing with the DNSSEC key Rollover timing
and all that manual and automation tools dependencies, why not simply use a
key revocation list just like a certificate revocation list (CRL) ?
___
DNSOP mailing list
DNSOP
On 09/06/2018 03:14 AM, Shane Kerr wrote:
All,
On 2018-09-05 20:45, internet-dra...@ietf.org 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 WG of
the IETF.
Title : Reve
On Mon, Sep 10, 2018 at 09:48:05AM -0700, Paul Vixie wrote:
> Andrew Sullivan wrote:
> > ...
> >
> > I agree with Paul Vixie that classes were never defined well enough to
> > be made to work properly, at least at Internet scale.
>
> this thread has further cemented my prejudice against CLASS. how
Andrew Sullivan wrote:
...
I agree with Paul Vixie that classes were never defined well enough to
be made to work properly, at least at Internet scale.
this thread has further cemented my prejudice against CLASS. however, it
has also motivated me to define it well enough that we can create
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 cut this
introductory paragraph, however.)
Please refer to https:/
I have to disagree. Classes could quite easily be made to work at internet
scale.
The only thing that would cause issues is vendors that have taken short cuts.
Is it that hard to add root.hint for class10 when we want to use class10?
--
Mark Andrews
> On 10 Sep 2018, at 22:55, Andrew Sulli
Dear colleagues,
On Tue, Sep 04, 2018 at 12:29:30AM -0400, StJohns, Michael wrote:
> Actually, 5.2 suggests that a master file (not zone) should contain a
> single class and single SOA record. That’s not the same thing as limiting
> a zone to a single class AFAICT.
I believe it is the same thin
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 cut this
introductory paragraph, however.)
Please refer to https:
22 matches
Mail list logo
