my mailbox is not filled with crap from spammers, if that is what you
mean. it's not empty either. :)
if you want to kill off NSAP-PTR, I'd support that.
/Wm
On Mon, Mar 26, 2018 at 11:44 AM, Dick Franks wrote:
>
> On 26 March 2018 at 16:42, Paul Vixie wrote:
>
>>
>>
>> Ondřej Surý wrote:
>>
concur with Pauls assertions wrt "long tail". Picking on specific RR types
to remove is a high maintenance method to put the camel on a diet.
Laudable but maybe not worth the efforts needed to clean up the installed
base. Perhaps these two ideas might be a better way to simplify things.
1) remove
> On Mar 24, 2018, at 10:57 PM, Ondřej Surý wrote:
>
> It’s interesting that there’s some NULL RR Type usage in your zones, I
> suppose that some experiments.
Or, maybe everyone's recent favorite, RFC 8145:
5.1. Query Format
A Key Tag query consists of a standard DNS query of type NULL a
> On 29 Mar 2018, at 9:05 am, Frederico A C Neves wrote:
>
> On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote:
>> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
>>> No. You can have multiple nsec3 chains in a zone at the same time. Only one
>>> is active. Some
On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote:
> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
> > No. You can have multiple nsec3 chains in a zone at the same time. Only one
> > is active. Some may be incomplete.
> >
> > Named builds and destroys chains i
On Wed, Mar 28, 2018 at 05:43:29PM -0400, Robert Edmonds wrote:
> Whatever the long gone original experiments that NULL was intended for
> that are alluded to in STD 13, NULL has some present day operational
> utility in that it's explicitly defined as carrying as much arbitrary
> data as can fit,
Ondřej Surý wrote:
> It’s interesting that there’s some NULL RR Type usage in your zones, I
> suppose that some experiments.
Whatever the long gone original experiments that NULL was intended for
that are alluded to in STD 13, NULL has some present day operational
utility in that it's explicitly
On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
> No. You can have multiple nsec3 chains in a zone at the same time. Only one
> is active. Some may be incomplete.
>
> Named builds and destroys chains incrementally to avoid large changes.
>
> Timely ness of changes is more impo
No. You can have multiple nsec3 chains in a zone at the same time. Only one is
active. Some may be incomplete.
Named builds and destroys chains incrementally to avoid large changes.
Timely ness of changes is more important than volume of changes.
--
Mark Andrews
> On 29 Mar 2018, at 02:0
Also, this "Camel" in the presentation may have been a mythological
beast, but the real and existing DNS Camels that struggle with their
backs breaking under the weight of DNS are the DNS implementations,
especially the open source ones that are underfunded and understaffed.
If someone wants to ad
On Wed, Mar 28, 2018 at 2:41 PM, Suzanne Woolf wrote:
> Note this discussion has started to split into (at least) two: cleaning up
> the DNS standard (protocol, documents, or both), possibly in a new WG; and
> whether/how the existing DNSOP WG needs to adjust its efforts.
>
>> On Mar 27, 2018, a
On Thu, Mar 29, 2018 at 01:18:36AM +0530, Mukund Sivaraman wrote:
> it applies. If it is nameserver territory, I absolutely want to see an
> implementation in *any* of the major DNS implementations. By major, I
> mean the popular ones (e.g., PowerDNS, NSD, Unbound, Knot, etc.) This is
Sorry, that
On Wed, Mar 28, 2018 at 05:29:18PM +0200, Matthijs Mekking wrote:
> As mentioned in the meeting, I am in favor of requiring implementations
> before drafts become standards.
>
> However, I would be opposed to limit acceptable implementations to the few
> major open source DNS implementations (defi
On Wed, Mar 28, 2018 at 04:46:52PM +0100, Tony Finch wrote:
> bert hubert wrote:
> >
> > Well to allow the one remaining closed source DNS implementation some room,
>
> authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign
> recursive services: Google OpenDNS Quad9
> COTS: Nominum
Bert,
On Wed, Mar 28, 2018 at 05:24:33PM +0200, bert hubert wrote:
> On Wed, Mar 28, 2018 at 08:49:39PM +0530, Mukund Sivaraman wrote:
> > I'd raise the bar even higher, to see complete implementation in a major
> > open source DNS implementation when it applies. Sometimes implementation
> > probl
Tony Finch wrote:
...
I still prefer the name "UXFR (update-style IXFR)" :-)
:-). +1, if we're voting.
--
P Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
matt, the rfc document set is innately time-series. this was seen as a
strength compared to some "document set in the sky" that would be
updated periodically with lineouts and additions, like for example legal
codes or the ARIN PPML. i think you're very close to saying we need the
latter in add
Matthijs Mekking wrote:
On 03/28/2018 05:19 PM, Mukund Sivaraman wrote:
On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote:
I would say that most things we have adopted in the past few
years do have some implementations to reference. Not when drafts
are adopted, but generally before w
dave, HEREIS. --paul
internet-dra...@ietf.org wrote:
...
https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-06
...
in: 1. Introduction
s/resource records/resource record types/ (two occurrences)
in: 1.1. _Underscore Scoping
s/existing resource record/existing resource record type/
s/spec
open letter.
Jim Reid wrote:
On 28 Mar 2018, at 18:02, Phillip
Hallam-Baker wrote: ... long rant snipped
... Well that is how I plan to go forward at any rate.
Good for you. Please come back to the IETF once you've figured it all
out and have running, interoperable code.
jim, i've been gu
> On 28 Mar 2018, at 18:02, Phillip Hallam-Baker wrote:
> ... long rant snipped ...
> Well that is how I plan to go forward at any rate.
Good for you. Please come back to the IETF once you've figured it all out and
have running, interoperable code.
A while back, I realized that I needed a full DNS client implementation to
do proper DNS discovery. So I reduced the existing specs to a file that
does capture the syntax:
https://github.com/hallambaker/Mathematical-Mesh/blob/master/Libraries/Goedel.Discovery/Domainer.domainer
I use that file to
tjw ietf wrote:
I should qualify my comments on Route 53 - I don't think they are
something we should emulate, more of an example of how 3rd party vendors
get away with an overly-minimal set of resource records. The words I
have to describe them are generally not polite.
i remember being un
On Wed, Mar 28, 2018 at 05:43:15PM +0200, Matthijs Mekking wrote:
> > One comment,
> >
> > [3.1] As section 3 states that MIXFR is DNSSEC aware we need text
> > regarding NSEC3PARAM update as well.
> >
> > For that I suggest to change 3.1 section name and include an extra
> > paragraph.
> >
Job Snijders wrote:
> On Wed, Mar 28, 2018 at 3:48 PM, Tony Finch wrote:
> > Related to the current discussion, does anyone have any links to
> > implementations of CSYNC?
>
> https://trac.ietf.org/trac/dnsop/wiki/implementation_reports
>
> I did the hard work and created an empty page ;-)
"Than
On Wed, Mar 28, 2018 at 3:48 PM, Tony Finch wrote:
> Related to the current discussion, does anyone have any links to
> implementations of CSYNC?
https://trac.ietf.org/trac/dnsop/wiki/implementation_reports
I did the hard work and created an empty page ;-)
__
On Wed, Mar 28, 2018 at 3:46 PM, Tony Finch wrote:
> bert hubert wrote:
>>
>> Well to allow the one remaining closed source DNS implementation some room,
>
> authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign
> recursive services: Google OpenDNS Quad9
> COTS: Nominum
Those can
On 28/03/2018 15:43, Pieter Lexis wrote:
> The draft speaks of an OPCode in the IANA section and of a meta
> RRType in the examples and Introduction section, which is it?
>
> If it is an RRType, some words need to be added about the fact that
> current resolvers will pass through the MIXFR query
Related to the current discussion, does anyone have any links to
implementations of CSYNC?
Tony.
--
f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode
Southwest Forties, Cromarty, Forth, Tyne, West Dogger: Cyclonic becoming
easterly later, 5 to 7. Rough or very rough. Occasional rain.
bert hubert wrote:
>
> Well to allow the one remaining closed source DNS implementation some room,
authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign
recursive services: Google OpenDNS Quad9
COTS: Nominum
... I have probably missed several ...
Tony.
--
f.anthony.n.finchh
Frederico,
On 03/28/2018 05:06 PM, Frederico A C Neves wrote:
Hi Matthijs,
On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote:
All,
It's been a while, but I have put up a new version of the MIXFR draft:
https://tools.ietf.org/html/draft-mekking-mixfr-02
The IETF 101 Hack
Richard,
On 03/28/2018 04:44 PM, Richard Gibson wrote:
I really like this document, especially the changes to version 02.
Thanks:)
One comment: Section 3.6 (Replace an RRset) specifies that "RDLENGTH
must be non-zero" _and_ that "The same syntax is used to delete an RRset
and to replace an
An enterprise company with rather large zone which update often are "highly
interested" in MIXFR.
But we may be the exception rather than the rule.
Tim
On Wed, Mar 28, 2018 at 11:24 AM, bert hubert
wrote:
> On Wed, Mar 28, 2018 at 08:49:39PM +0530, Mukund Sivaraman wrote:
> > I'd raise the bar
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 : DNS Scoped Data Through '_Underscore' Naming of
Attribute Leaves
Author : Dave Crocker
Folks,
(long note. couldn't make it shorter...)
This has been an unusually challenging journey. None of the recent
comments in support of a 'simplifying' view for this registry resonated.
Quite the opposite. In effect, it seemed to me as if RR type would be
a lookup key, which frankly sound
On 03/28/2018 05:19 PM, Mukund Sivaraman wrote:
On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote:
I would say that most things we have adopted in the past few years do have
some implementations to reference.
Not when drafts are adopted, but generally before we head to WGLC I've
always
On Wed, Mar 28, 2018 at 08:49:39PM +0530, Mukund Sivaraman wrote:
> I'd raise the bar even higher, to see complete implementation in a major
> open source DNS implementation when it applies. Sometimes implementation
> problems are very revealing (client-subnet should have gone through
> this).
Wel
On 27 March 2018 at 20:17, Paul Vixie wrote:
> I think we're discussing the same idea from different perspectives.
>>
>
> i think so, yes.
>
> I think writing a new document that references other documents to say
>> "here's the sections in each of these you need to implement" without
>> actually
Pieter,
On 03/28/2018 04:43 PM, Pieter Lexis wrote:
Hi Matthijs,
On Wed, 28 Mar 2018 15:31:57 +0200
Matthijs Mekking wrote:
It's been a while, but I have put up a new version of the MIXFR draft:
https://tools.ietf.org/html/draft-mekking-mixfr-02
The draft speaks of an OPCode in the
On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote:
> I would say that most things we have adopted in the past few years do have
> some implementations to reference.
> Not when drafts are adopted, but generally before we head to WGLC I've
> always wanted to see someone
> who implemented the o
Tony,
On 03/28/2018 04:08 PM, Tony Finch wrote:
Matthijs Mekking wrote:
It's been a while, but I have put up a new version of the MIXFR draft:
https://tools.ietf.org/html/draft-mekking-mixfr-02
I've had a quick skim and it looks nice.
Thanks.
Suggestions for 2nd paragraph of intr
Hi Matthijs,
On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote:
> All,
>
> It's been a while, but I have put up a new version of the MIXFR draft:
>
> https://tools.ietf.org/html/draft-mekking-mixfr-02
>
> The IETF 101 Hackathon lead to the revival of this draft.
>
> Changes
I would say that most things we have adopted in the past few years do have
some implementations to reference.
Not when drafts are adopted, but generally before we head to WGLC I've
always wanted to see someone
who implemented the option in some manner.
But yes, agree.
On Wed, Mar 28, 2018 at 10:5
I really like this document, especially the changes to version 02.
One comment: Section 3.6 (Replace an RRset) specifies that "RDLENGTH
must be non-zero" _and_ that "The same syntax is used to delete an RRset
and to replace an RRset with an RR whose RDLENGTH is zero". I think the
former should
On Wed, Mar 28, 2018 at 04:43:53PM +0200, Pieter Lexis wrote:
> Hi Matthijs,
>
> On Wed, 28 Mar 2018 15:31:57 +0200
> Matthijs Mekking wrote:
>
> > It's been a while, but I have put up a new version of the MIXFR draft:
> >
> > https://tools.ietf.org/html/draft-mekking-mixfr-02
>
> The dra
"Transport of a query may be by either UDP or TCP. If an IXFR query
is via UDP, the IXFR server may attempt to reply using UDP if the
entire response can be contained in a single DNS packet. If the UDP
reply does not fit, the query is responded to with a single SOA
record of the serve
I would love to see a hard requirement for implementations &
implementation reports (like IDR has) in the charter or in the working
group house rules. Early implementations (perhaps even during the
hackathon) can reveal implications that might have been missed while
designing the draft. In additi
Hi Matthijs,
On Wed, 28 Mar 2018 15:31:57 +0200
Matthijs Mekking wrote:
> It's been a while, but I have put up a new version of the MIXFR draft:
>
> https://tools.ietf.org/html/draft-mekking-mixfr-02
The draft speaks of an OPCode in the IANA section and of a meta
RRType in the examples an
Matthijs Mekking wrote:
>
> It's been a while, but I have put up a new version of the MIXFR draft:
>
> https://tools.ietf.org/html/draft-mekking-mixfr-02
I've had a quick skim and it looks nice.
Suggestions for 2nd paragraph of intro:
To keep the deltas small in zone transfers, we need t
I should qualify my comments on Route 53 - I don't think they are something
we should emulate, more of an example of how 3rd party vendors get away
with an overly-minimal set of resource records. The words I have to
describe them are generally not polite.
Tim
On Wed, Mar 28, 2018 at 4:38 AM, T
On 3/28/2018 5:49 AM, Martin Hoffmann wrote:
draft-ietf-acme-acme defines _acme-challenge for TXT records.
Thanks. Added to the next version.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www
Note this discussion has started to split into (at least) two: cleaning up the
DNS standard (protocol, documents, or both), possibly in a new WG; and
whether/how the existing DNSOP WG needs to adjust its efforts.
> On Mar 27, 2018, at 3:49 AM, Ondřej Surý wrote:
>
> Hi Suzanne,
>
>> If the W
All,
It's been a while, but I have put up a new version of the MIXFR draft:
https://tools.ietf.org/html/draft-mekking-mixfr-02
The IETF 101 Hackathon lead to the revival of this draft.
Changes after the three year sleep:
- I removed the IXFR Gone Wild section. This document should focus i
Hi,
should probably do this more systematically, but I just
stumbled over another underscore label in the ACME draft:
draft-ietf-acme-acme defines _acme-challenge for TXT records.
The draft seems to be in Last Call right now, so it might
be an RFC before the registry is established.
Kind regard
ietf-dns...@johnbond.org wrote:
>
> https://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-01 is
> worth a mention specifically in relation to PMTUD
Thanks for the pointer!
Tony.
--
f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode
Northeast Viking, North Utsire: Southeas
On 28.3.2018 01:18, Geoff Huston wrote:
>> 3rd proposal
>>
>> We have one more thing which needs more manpower to be verified. Right
>> now, the section 3.1. Preconditions is:
>>
>>> 3.1. Preconditions
>>>
>>> All of the following conditions must be met to trigger special
>>> pro
Michael StJohns wrote:
>
Interesting thoughts, thanks. I have a slightly different starting point,
which doesn't disagree with your argument, but leads to somewhat different
consequences.
> Proposition 1 (P1): The initial selection of a root of trust (ROT) on behalf
> of a validator ALWAYS invo
I have looked at the same problem Bert has, but he did present it much
better than I could. When I started thinking about this, I approached
it from the point of view of "If I have to give a co-worker a document
on how to build a DNS Server (Authoritative or Resolver), what would I
need to g
58 matches
Mail list logo
