As we've seen to good summary on requirements for on a well-behaved DNS
delegation of a domain name, Patrik Wallström and myself has written an
Internet-Draft [1] describing such requirements. The requirements were
developed within the CENTR Test Requirements Task Force (TRTF) and most of the
Moin!
On 8 Feb 2016, at 9:57, Jakob Schlyter wrote:
At this point, we're seeking more public comments - on this mailing
list (unless the chairs disapproves), on the our issue tracker [4] or
via email to the authors.
Thanks a lot for this work. I certainly would like dnsop to work on
this.
I
Jakob,
At 2016-02-08 09:57:15 +0100
Jakob Schlyter wrote:
> As we've seen to good summary on requirements for on a well-behaved DNS
> delegation of a domain name, Patrik Wallström and myself has written an
> Internet-Draft [1] describing such requirements. The requirements were
> developed wi
In message <3a6ef5a0-928c-4f10-bd68-265dae87f...@kirei.se>, Jakob Schlyter writ
es:
7.4 is per DNSSEC algorithm in the DS RRset.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
On 8 feb. 2016, at 11:00, Ralf Weber wrote:
> I would soften some of language and have a question.
>
> 5.1. There are use cases where the serial number rarely if ever is the same
> on all servers and it's only really used inside communication for a given
> domain and not during resolution. So
Jakob, Patrik
thanks for writing this up, a great start.
On first read this document seems to be duplicating what is in
https://tools.ietf.org/html/rfc1912
It is hard to see what is new and what is the same.
There are number of assumptions in the current draft, that only apply when
the DNS conten
Olafur,
> On 08 Feb 2016, at 13:57, Ólafur Guðmundsson wrote:
>
> Jakob, Patrik
> thanks for writing this up, a great start.
>
> On first read this document seems to be duplicating what is in
> https://tools.ietf.org/html/rfc1912
> It is hard to see what is new and what is the same.
Yes, som
On 08/02/2016 12:07, Jakob Schlyter wrote:
> On 8 feb. 2016, at 11:00, Ralf Weber wrote:
>> 6.2 The name servers SHOULD NOT belong to the same AS I would drop
>> that requirement altogether or make it a MAY. We really should not
>> tell people how to build networks from the DNS world.
>
> I wo
On Mon, Feb 8, 2016 at 2:00 AM Ralf Weber wrote:
> Moin!
>
> On 8 Feb 2016, at 9:57, Jakob Schlyter wrote:
> > At this point, we're seeking more public comments - on this mailing
> > list (unless the chairs disapproves), on the our issue tracker [4] or
> > via email to the authors.
> Thanks a lot
On 8 Feb 2016, at 4:07, Jakob Schlyter wrote:
6.2 The name servers SHOULD NOT belong to the same AS
I would drop that requirement altogether or make it a MAY. We really
should not tell people how to build networks from the DNS world.
I would agree, but on the other hand it's apparent that a l
Evan Hunt wrote:
>
> Choose an arbitrary (preferably determinate) rrset to return, and
> include its covering signature if it exists and DO=1 so the response can
> validate.
Right.
My code currently just picks the first RRtype it gets from the backend
data store (or the type covered if the first
> On Feb 8, 2016, at 10:33 AM, Tony Finch wrote:
>
> Doing anything more determinate would require an extra loop over the data
> to choose, before the loop that builds the response. (Actually I can
> probably avoid two loops if I'm clever.) I didn't think I cared enough to
> do that. However som
On Sun, Feb 7, 2016 at 2:16 PM, Tony Finch wrote:
> Another question:
>
> In order to minimize responses even further, I have made my code omit or
> include signature records depending on whether DO=0 or DO=1. That is, and
> ANY query with DO=0 gets one arbitrary unsigned RRset in response, and a
Ólafur Guðmundsson wrote:
> Tony: the draft says right now: [...]
>
> Is that not sufficient ?
The most relevant bit in the current draft is:
If the DNS query includes DO=1 and the QNAME corresponds to a zone
that is known by the responder to be signed, a valid RRSIG for the
RRSets in
On Mon, Feb 08, 2016 at 10:37:09AM -0500, Jared Mauch wrote:
> Or just having the TCP implementation in BIND get improved as it’s clear there
> are some more people pushing in this direction. I’m looking at just putting
> something like DNSDIST on my hosts to process TCP and balance it across
> mu
My 2 cents…
I don’t think any DNS RFC should be tied to any specific element of Internet
routing technology. Keep it relatively generic and avoid mention of “ASes” and
the like, since this RFC may outlive the use of ASes for Internet routing.
”Path diversity”, “link diversity”, “network-level r
On Mon, Feb 8, 2016 at 3:38 PM Darcy Kevin (FCA)
wrote:
> My 2 cents…
>
>
>
> I don’t think any DNS RFC should be tied to any specific element of
> Internet routing technology. Keep it relatively generic and avoid mention
> of “ASes” and the like, since this RFC may outlive the use of ASes for
>
17 matches
Mail list logo
