On 23-10-2020 00:12, Tony Finch wrote:
> Ralph Dolmans wrote:
>>
>> Thanks for your feedback, appreciated!
>
> Thanks for the response!
>
> I thought of another thing:
>
> Some of the points in section 5 (on limiting the number of queries and the
> perfor
Hi Tony,
Thanks for your feedback, appreciated!
On 14-10-2020 20:15, Tony Finch wrote:
> A few questions and suggestions:
>
> Section 3, algorithm step 5: what is a "hidden QTYPE"?
The QTYPE in the incoming query. We made the text more consistent and
now always use "original QTYPE".
>
> Also
ld be very useful to have
> your slides (even if draft) ready for this.
>
> If you have questions or concerns you can contact the Programme Committee:
>
> https://www.dns-oarc.net/oarc/programme
>
> via
>
> Ralph Dolmans, for the DNS-OARC Programme Committee
>
>
ing up to the workshop. We will work with all accepted
speakers on a convenient time for all. It would be very useful to have
your slides (even if draft) ready for this.
If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via
Ralph D
he quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.
If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via
Ralph Dolmans, for the DNS-OARC Programme Committee
OARC depends on s
Hi all,
I made an Extended DNS Errors implementation in Unbound during the
IETF104 hackathon. Implementing the code that handles the errors was
rather straightforward, the difficult part is (as Stéphane already
pointed out) finding the right locations in the code for the individual
errors. Some
ssions
SHOULD include slides. Draft slides are acceptable on submission.
If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via
Ralph Dolmans, for the DNS-OARC Programme Committee
OARC depends on sponsorship to fund its wor
On 21-01-19 11:22, Peter van Dijk wrote:
> I oppose adoption. Any implementation of this draft will actively hurt the
> DNS and the Internet, and thus publication as an RFC will actively hurt the
> DNS and the Internet.
I agree with Peter. This workaround does more harm than good and should
ns, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.
If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via
Ralph Dolmans, for the joint Programme Committee
Hi,
On 03-05-18 10:15, Geoff Huston wrote:
> We have also taken the implementation comments posted to the WG mailing list
> and collected them in a new section titled "Implementation Experience” in the
> light of Suzanne’s request
This draft is by now implemented in Unbound and is in version
Jun 2018 - Submissions and Registrations open via Indico
13 Jul 2018 - Deadline for submission
17 Aug 2018 - Contribution list published
14 Sep 2018 - Full agenda published
06 Oct 2018 - Deadline for slideset submission
13 Oct 2018 - Workshop
Ralph Dolmans, on behalf
On 26-03-18 12:04, Michał Kępień wrote:
>> What is the expected behaviour given
>> example.net CNAME kskroll-sentinel-is-ta-.example.com
>> when you query for example.net when the key-tag does not match
>> a root TA? etc.
>
> This question is still outstanding as of version -08 of the draft.
It
On 23-03-18 13:13, Warren Kumari wrote:
> Dear DNSOP,
>
> Please clearly express a preference for:
> 1: Keeping the current label -- kskroll-sentinel-is-ta-20326.example.com
> 2: Changing it to the new label -- root-key-sentinal-is-ta-20326.example.com
I prefer the second option (with sentinel
Hi,
On 21-03-18 16:58, Petr Špaček wrote:
> draft-spacek-edns-camel-diet-00 is a new draft which partially reacts to
> The Camel talk from yesterday, and is based on plan of open-source DNS
> software vendors to get rid of EDNS workarounds.
>From the introduction:
> EDNS version 0 was
On 22-02-18 10:03, Petr Špaček wrote:
> I would prefer decimal for user-friendliness, and zero padding to make
> implementation easier and faster.
+1, decimal and zero padded to 5 digits to make it fixed length labels.
-- Ralph
___
DNSOP mailing list
Hi Warren, all,
On 15-01-18 02:51, Warren Kumari wrote:
> The (new) rules:
> A: If the qname starts with _is-ta, and the included keyid is *NOT* in
> the trust store, the resolver changes the answer to a SERVFAIL
> (otherwise things proceed normally).
> B: If the qname starts with _not-ta and the
e editorial nits:
- trust anchor vs Trust Anchor, both used in document
- section 2: aplied -> applied
- section 3, Vleg: "RRSET" -> "RRset"
- section 3, Vleg: "an A record" -> "an A or RRset"
Regards,
-- Ralph Dolmans
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hi,
Maybe I'm missing something, but it is not clear to me whether this
document (-06) allows generation of NODATA answers using matching NSEC
records that do not have the QTYPE set in the type bitmap.
I don't see it explicitly mentioned. The RFC4035 update in section 7
seems to allow it (or at
18 matches
Mail list logo
