Re: [DNSOP] Subject: request for adoption: draft-edns-presentation
Hi Libor, Tom, Thanks for this, I believe this will be a good extension to the EDNS specification to help operators hunt down issues. I support its adoption by the WG. Should the WG disagree, please submit it as an individual submission. On Wed, 2022-11-23 at 20:25 +0100, libor.peltan wrote: > Hi DNSOP, > we have prepared a specification document (see below), which fills a > gap > that appears to be missing currently — The EDNS(0) textual and JSON > format. > It also fixes a "specification bug" in an existing and related RFC. I wonder if it should update RFC 6891 and all related OPTION RFCs as well. I also wonder if it could make sense to add guidance on how to choose the correct presentation format for newly drafted EDNS options so future option-drafts and documents have presentation formats in there. > We would also welcome any improvement suggestions and useful > corrections. However, fearing discussion loops arguments about > details, > we encourage to moderate discussion of details, such as if some > fields > in a specific option shall be separated by commas or slashes. > This document is full of design decisions that might be differently > appealing to everyone. The format might seem complicated, but the > goal > was best possible human readability. > And the more general (and important) goal is to make the standard > useful, so that it gets adopted by implementations. I had a cursory glance and it looks quite complete. I'll try to get a better reading in soon. Best regards, Pieter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] FOSDEM 2023 DNS Devroom Call for Presentations
Hello DNS enthusiasts and other developers, After three earlier successful and packed DNS devrooms at FOSDEM 2018, 2019, and 2020, we are happy to announce a half-day DNS devroom at FOSDEM 2023. As with the previous events, we hope to host talks anywhere from hardcore protocol stuff, to practical sessions for programmers that are not directly involved with DNS but may have to deal with DNS in their day to day coding or system administrators responsible for DNS infrastructure. We have been allotted a room on Saturday the 4th of February 2023, from 15:00 to 19:00 (CET). If you have something you’d like to share with your fellow developers, please head to pentabarf at https://penta.fosdem.org/submission/FOSDEM23. Examples of topics are measuring, monitoring, DNS libraries, anecdotes on how you’ve (ab)used the DNS, and group discussions of upcoming technologies. For the upcoming technologies, we're looking for submissions on Applications Doing DNS (ADD), SVCB/HTTPS records and applications thereof, and stub-resolver configuration. Here’s the 2020 schedule, for your inspiration: https://archive.fosdem.org/2020/schedule/track/dns/. We expect to schedule 30 minutes per talk, including questions, but if you need more or less time, we can discuss this. The deadline for submissions is December 7th 2022. If you have a FOSDEM Pentabarf account from a previous year, please use that account. Reach out to dns-devroom-mana...@fosdem.org if you run into any trouble. this CfP lives online at https://blog.powerdns.com/2022/11/11/fosdem-2023-dns-developer-room-call-for-participation/ - any important changes will be posted at least there See you there! Cheers, The FOSDEM 2023 DNS Devroom organizers ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Hi Joe, On 5/10/21 1:42 AM, Joe Abley wrote: > On May 9, 2021, at 19:27, Paul Hoffman wrote: > >> If I'm wrong about this being as good as it can be, there must be an item >> delimiter that is better than a comma. I am not thinking creatively enough >> to figure out what might be better than a comma. I'd be happy to hear >> proposals for a better item delimiter. > > I am quite behind on this topic, but I presume there's a reason to put all > these key-value pairs in a list in one RR? > > If we compare the two fictional RRTypes EG1 and EG2 illustrated below: > > example.com. EG1 key1=value1,key2=value2,... > > example.com. EG2 key1 value1 > example.com. EG2 key2 value2 > > It seems to me that EG2 avoids the need for delimiters at all. There's a bit > of overhead resulting from the need for a larger RRSet but it's not obvious > that that's a proble> > If the SvcParams field of the SVCB RR was a domain name rather than an > explicit list this would all look a lot more DNS-like as far as parsing goes. > This would also allow a single set of SvcParams key-value pairs to be > included in different service bindings without having to be sent each time or > to be bound to something provided a service provider (SVB in customer.org > zone that refers to SvcParams.provider.com) giving the provider some ability > to maintain some aspects of the service). You then invite the following issues: Clients need to match the tuple (ownername + prio + target) and get all data from all matched rrsets, whereas now you get all that data in one piece of rdata. A client also can't figure out (if not doing DNSSEC valdiation themselves) if you have received all the SVC data for a certain name. Cheers, Pieter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Hi Dick, On 5/10/21 1:02 PM, Dick Franks wrote: > My objection is narrowly focussed on the escape mechanism, nothing > more. Changing the delimiter is neither necessary nor relevant. > > I am happy to contribute the necessary words. If you have the words to fix this issue that would need to changes the code but clears everything up, do it :). Cheers, Pieter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Hi Dick, On 5/9/21 2:01 PM, Dick Franks wrote: > Pre-processing of '\\,' into the RFC1035 standard '\,' is > superficially attractive, but also fraught with danger. > > A parser could have some fun with this one: > > $ORIGIN example.com > @ SVCB 1 foo > key6="\032\001\013\184\000\000\000\000\000\000\000\000,\000" > ; a.k.a. ipv6hint=2001:db8::5c5c:2c00 A zone owner/editor would never even think of typing in IP addresses like that. And no decoder should ever write that out (and if it does, would a zone-owner read it?). Also, when using the generic format, the full value should be the 'wire' format so there's comma delimiter between values. For ALPN you'd have [value1 len][value 1][value2 len][value2] and for key6 [encoded first ipv6 address bytes][encoded second ipv6 address bytes]. > The spec only needs to say that a comma needs to be escaped ( \, ) in > order to be disregarded as a separator. > BIND, NSD, Net::DNS, and PowerDNS can all do this, so there is little > mileage in claiming that it is not possible. > > The "impossible" can be made possible by doing the right things in the > correct order. > Selecting the right things and the correct order is left as an > exercise for the student. >From what I gather, this is the case? With the caveat that there is a 2-step process for parsing the values for keys defined as paramlists. Cheers, Pieter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Hi folks,
On 5/6/21 10:16 PM, Dick Franks wrote:
> On Thu, 6 May 2021 at 19:11, Ben Schwartz wrote:
>> On Thu, May 6, 2021 at 8:50 AM Dick Franks wrote:
>>> BIND, NSD, and Net::DNS are all able to arrive at implementations of
>>> SVCB using the RFC1035 standard escape conventions, which demonstrates
>>> beyond reasonable doubt that recognising "\\," is not an essential
>>> requirement.
>>
>> I disagree: what you are proposing is a deviation from RFC1035 escape
>> conventions, and what the draft does is specifically to ensure that no such
>> deviation is required.
>
> I am advocating strict adherence to RFC1035 escape conventions. You
> are the one proposing to deviate.
>
>> ... I have now encountered multiple codebases where modifying the RFC1035
>> char-string parsing in the way that you suggest would be prohibitively
>> complex, and that complexity will only grow over time as new SvcParamValues
>> are defined.>
> If the development cost is prohibitive, the obvious solution is to use
> BIND, NSD, or one of the other respectable implementations which are
> certain to be not far behind. If Google cannot afford the license
> fee, a six line perl Net::DNS script could be used to translate
> RFC1035 compliant SVCB RRs into RFC3597 format at nil cost.
, respectively).
> [...]
> That is no justification at all. SPF people can do whatever they
> like within the arguments of a TXT record.
For PowerDNS, we treat the parsing of SVCParams as a two-step process.
First we use the normal rfc1035 character decoder on the full SVCParam
value, after which we apply the value-list parser. The former parses
'foo\\,bar' into 'foo\,bar' that is then parsed to a list of length 1
with value {'foo,bar'}. So nothing changes from the perspective of the
rfc 1035 parser.
I can see how this might be confusing to those writing zone contents and
would support a solution that either prohibits comma's in SVCParam list
values or a different value separator that is not allowed to be embedded
in values.
Regards,
Pieter
--
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt
Hi folks, On 3/22/21 5:29 PM, Willem Toorop wrote: > [...] > Would be good to have that in a test vector ;). Hence the inclusion of the unsorted keys vector :). > Excellent! How SHOULD it enforce? By failing to load or by fixing. This is all implementation specific of course :). For PowerDNS we don't pre-parse the zones when serving (being a database driven server) so we have a tool (`pdnsutil check-zone`) that will warn/error if things are wrong with records, where we're covering most of these cases. We'll have some sanity checking in-line (when serving), but there's no way we will validate all constraints at runtime (we will probably when you use the API to manipulate records, but that is not yet implemented) > Most here tilt to *failing to load*, so these should fail to load: > [...] > > I think it would be good to have this added to the test-vectors appendix. I'll try to update the vectors this week, changing the format and adding some missed cases as well. Cheers, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt
Hi Willem, On 3/19/21 11:47 AM, Willem Toorop wrote: > That'd be nice! PR is here [1]. > Do you also have tests for peculiar/corner and failure cases? I'm a little bit unsure what you men with this :). The code is here[2]. I've also opened a PR updating our parser for the draft-03 changes for multiple values, that one also has some tests for the value parser[3]. Cheers, Pieter 1 - https://github.com/MikeBishop/dns-alt-svc/pull/307 2 - https://github.com/PowerDNS/pdns/blob/3a63bb5fca1c45a6e9dee808a56ca6cbea2be0d8/pdns/test-dnsrecords_cc.cc#L209-L230 3 - https://github.com/PowerDNS/pdns/pull/10074/files#diff-1c55ae7b2d1073637c05a035de9ef6688ecffb209e50b3bef8b3d9ea1c5a329dR308-R393 -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt
Hi Willem, Ben, On 3/19/21 11:14 AM, Willem Toorop wrote: > Also, it would have been nice to have some test-vectors of RR's in > presentation format and wire format (in hexdump) in an appendix in the > document, to assist in the creation of interoperable implementations. > Maybe this can still be added? +1000 The PowerDNS unit tests already has a bunch of tests that do the presentation -> wire -> presentation roundtrip. I could convert those to using example.com, use some more hex and send a PR to the authors should they want this. Cheers, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-svcb-https
Hello WG, On 3/18/21 9:53 PM, Tim Wicinski wrote: > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, please > speak out with your reasons. I re-read the draft-03 last week and just had a look at the diff to -04. There are two things I find unclear about the current draft, and that is the handling of automatic mandatory keys. Especially the rules on how to verify the record is consistent (section 7). The draft mentions The SvcParamKey "mandatory" is used to indicate any mandatory keys for this RR, in addition to any automatically mandatory keys that are present. and This SvcParamKey is always automatically mandatory, and MUST NOT appear in its own value-list. Other automatically mandatory keys SHOULD NOT appear in the list either. (Including them wastes space and otherwise has no effect.) This means an HTTPS record MUST have a port and a no-default-alpn SVCParam in both the presentation and wire format, without the keys being present in the mandatory key? It would be good to add an example or some clarification here. The second question arises for the "default set" of ALPNs. Section 6.1 says Each scheme that uses this SvcParamKey defines a "default set" of supported ALPNs, which SHOULD NOT be empty. To determine the set of protocol suites supported by an endpoint (the "SVCB ALPN set"), the client adds the default set to the list of "alpn-id"s unless the "no- default-alpn" SvcParamKey is present. The presence of an ALPN protocol in the SVCB ALPN set indicates that this service endpoint, described by TargetName and the other parameters (e.g. "port") offers service with the protocol suite associated with this ALPN protocol. The HTTPS record mentions that no-default-alpn is automatically mandatory, but also that alpn has a default value. Which would mean that that the default alpn is never used? Or is mandatory a hint to the end-client that it MUST understand the keys mentioned in order to use the RR? If that is the case, a few words to that effect would be good. I hope the rambling above makes the question clear. Cheers, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt
Hi, On 3/18/21 6:42 PM, Tommy Pauly wrote: > Personally, I’d prefer to see the name change, and not burn a codepoint, > as long as we’re not breaking any zone files. Agree. > I think the question is: does anyone have a zone that has actually > deployed the echconfig parameter? I see many responses with SVCB/HTTPS > records, but none with the echconfig in practice. If someone is aware of > a production deployment that can’t move, please speak up! We released PowerDNS Authoritative Server 4.4.0 with explicit draft-01 support. We can put the name-change in a future patch release, mention this in the the upgrade docs and add some code to log that the old name is in use for a few releases. We have not heard of any deployments that use SVCB/HTTP. Cheers, Pieter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-iana-class-type-yang
Hi folks, On 10/15/20 12:05 AM, Benno Overeinder wrote: > Current versions of the draft are available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ > > The Current Intended Status of this document is: Standards Track > > Benno Overeinder will be Document Shepherd. > > The authors have incorporated the comments of the working group in their latest revision -05. The chairs would like to thank Paul Wouters for his input during the various versions of the Internet Draft. > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, please speak out with your reasons. > Supporting statements that the document is ready are also welcome. It looks like the authors did a good job cleaning up the document. I don't see any issues regarding the content of the document. Best regards, Pieter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
On 8/5/20 11:13 PM, Mark Andrews wrote:
>> On 6 Aug 2020, at 04:51, Pieter Lexis wrote:
>> On 8/5/20 8:03 PM, Brian Dickson wrote:
>>> (I am not sure of the question/issue of including the SOA, or where that
>>> would go, but I'll defer to anyone who knows or has an opinion. My gut
>>> says, do whatever gets done for CNAME.)
>>
>> The SOA MUST go in the packet. As a compliant resolver talking to an
>> auth that does not implement SVCB will follow the chain and the auth
>> will respond with NODATA (and thus the SOA).
>
> You make a SVCB query you will get a CNAME if it exists at the QNAME, SVCB
> if it exists at the QNAME or you will get NODATA if neither exists.
If you
> find a CNAME you repeat at the target of the CNAME.
>
> If the server is SVCB aware it will then process the SVCB RRset and
add those
> records to the additional section, if any of those trigger additional
section
> processing those records too get added to the additional section. This is
> consistent with STD 13 that says words to the effect of “add anything
useful” (I’m
> not going to look up the exact words). The additional section rules
for SVCB say
> to add CNAME, SVCB, A and to the additional section.
The semantic rules for the Alias form lead me to believe that an SVCB at
the targetname *is* an answer to the question (no other SVCB at that
ownername, at the very least no Service mode SVCB at that name).
The end-clients (browsers, other programs actually querying for
SVCB/HTTPS)
Looking at section 5.4.1 ("Ranking Data") of RFC 2181, a non-SVCB
recursor might accept the data in the answer section:
[…]
+ Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative
answers,
+ Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.
On the other hand, a non-SVCB-aware resolver might even choose to drop
both the data in the ANSWER and ADDITIONAL section that do not match the
original QNAME. Thus only serving its client the SVCB alias record in
the ANSWER section, leading to the end-client re-querying for the
targetname SVCB record.
It would be good to know what most implementations do when they
encounter in-bailiwick data with a different owner name in both the
ANSWER and ADDITIONAL sections. Then the SCVB draft can pick the right
method:
* Semantically correct (chained SVCB in ANSWER, using 'CNAME chasing')
* Backwards compatible (All related data in ADDITIONAL)
Best regards,
Pieter
--
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
On 8/5/20 8:03 PM, Brian Dickson wrote: > > > On Wed, Aug 5, 2020 at 10:08 AM Ben Schwartz > <mailto:40google@dmarc.ietf.org>> wrote: > > On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis > mailto:pieter.le...@powerdns.com>> wrote: > ... > > Conceptually, AliasMode is not a CNAME: it only affects SVCB queries > (not other RR types), and can safely be implemented entirely as an > RFC 3597 Unknown RR Type. That suggests that it is at least safe, > and perhaps least-surprising, for the authoritative server to put > all responses for other owner names in the Additional section, as > the current text seems to indicate fairly clearly. > > > I beg to differ, in that I would view AliasMode as a constrained CNAME. I agree with Brian here. Compliant DNS servers (be it auth or recursor) MUST treat an Alias-mode SVCB (or derived) record as a CNAME for the purposes of processing that SVCB or derived record. i.e. foo.example.com SVCB 0 srv1.example.net == (logically) foo.example.com CNAME srv1.example.com when QType = SVCB, but not for any other QType. > What I would suggest is the following, paraphrased (i.e. please clean it > up before using in the I-D, if you agree it's the right semantics): > > * In-bailiwick CNAME, SVCB, A, and records SHOULD be added (and > for CNAME and SVCB, in-bailiwick RDATA for those SHOULD also be > iteratively processed for inclusion) > * CNAME and SVCB records MUST be placed in the Answer section (because > of existing CNAME rules and because of RRTYPE match to the query) > * A and records MUST be placed in the Additional section (since > those would not match the query RRTYPE of SVCB) +1 to this summary. It reflects how I see the semantics of alias mode as well. > (I am not sure of the question/issue of including the SOA, or where that > would go, but I'll defer to anyone who knows or has an opinion. My gut > says, do whatever gets done for CNAME.) The SOA MUST go in the packet. As a compliant resolver talking to an auth that does not implement SVCB will follow the chain and the auth will respond with NODATA (and thus the SOA). After reading section 4.2, I also think that a resolver that implements this MUST include the SOA as well if the final target has no SVCB record, to indicate that the answer to the actual question (example.com|SVCB) yielded NODATA after alias chaining. A compliant client can ignore the fact that the DNS says NODATA and use the A/ records from the ADDITIONAL section (or send a query for them based on the final target). > All the in-bailiwick stuff is essentially an optimization. Authority > servers may not implement that, and would still be compliant if they did > not. > Resolvers MUST be prepared to handle the non-inclusion of in-bailiwick > stuff from authority servers, as this would not be an error or violation > of the (eventual) RFC. Yes. > P..S. The text on this point has recently > changed: https://github.com/MikeBishop/dns-alt-svc/pull/199#discussion_r444979971. > One of the questions there is what should happen for > AliasMode->CNAME->ServiceMode->, all in-bailiwick. The draft > says "Clients and recursive resolvers MUST follow CNAMEs as > normal.", but it no longer says anything about authoritatives. > > > IMHO, I think this is correct, or at least consistent with what I wrote > above. (If there are any inconsistencies, could you highlight what those > would be, please?) I believe you are correct. Cheers, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
Hi folks,
Section 2.4.1 says
```
The primary purpose of AliasMode is to allow aliasing at the zone apex,
where CNAME is not allowed. In AliasMode, TargetName MUST be the name of
a domain that has SVCB, , or A records.
```
and section 4.1 says
```
When replying to a SVCB query, authoritative DNS servers SHOULD return
A, , and SVCB records in the Additional Section for any in-bailiwick
TargetNames.
```
Does this mean that the processing differs from 'regular' in-zone CNAME
processing? Where I define this processing as "look for the Target name
with the type from the query and use that result's status as query result".
Considering this zone (abbreviated):
```
svcb-alias.example.net SVCB 0 alias-target.example.net
alias-target.example.net A 192.0.2.1
```
What would be the correct response to a svcb-alias.example.net|SVCB query?
```
;; QUESTION SECTION:
;svcb-alias.example.net.IN SVBC
;; ANSWER SECTION:
svcb-alias.example.net. 3600IN SVBC3600 0 alias-target.example.net
example.net.IN SOA 3600[]
;; ADDITIONAL SECTION:
alias-target.example.net. 3600 IN A 192.0.2.1
```
or
```
;; QUESTION SECTION:
;svcb-alias.example.net.IN SVBC
;; ANSWER SECTION:
svcb-alias.example.net. 3600IN SVBC3600 0 alias-target.example.net
;; ADDITIONAL SECTION:
alias-target.example.net. 3600 IN A 192.0.2.1
```
With the former, implementers would be be able to reuse the existing
aliasing code paths. With the latter, changes will have to be made to
the codepath as the AliasMode is not a 'true' alias as CNAME is.
In the same vein, what happens in a zone like this (with the same
incoming query for svcb-alias.example.net|SVCB):
```
svcb-alias.example.net SVCB 0 alias-target1.example.net
alias-target1.example.net SVCB 0 alias-target2.example.net
alias-target2.example.net SVCB 1 . ipv4hint=192.0.2.1
alias-target2.example.net A 192.0.2.1
```
Do *both* alias-target{1,2}.example.net|SVBC records end up in the
ADDITIONAL section. Or are they (as is the case with an in-zone CNAME)
considered an answer and should they go into the ANSWER section?
I find the alias mode semantics (on the DNS-level) unclear and
under-specified in the draft. I look forward to guidance from the authors.
Best regards,
Pieter
--
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] SVCB and HTTPS SvcParam multiple value order on the wire
Hi folks,
I'm working on implementing SVCB and HTTPS in PowerDNS and I have some
questions about the wire-format for the multi-value parameters like
ipv{4,6}hint and alpn.
When there are multiple IP addresses in a hint, in what order should
they be on the wire? I would expect them to be ordered like an A/
RRSet's RDATA to be sorted as specified in 4034 section 6.3 ("… are
sorted by treating the RDATA portion of the canonical form of each RR as a
left-justified unsigned octet sequence in which the absence of an octet
sorts before a zero octet."). The draft says the hints are "an unordered
collection", but it would be great to mandate an on-the-wire ordering
here.
This will only work, of course, if multi-valued SvcParams are a set
(where duplicates are disallowed/ignored), which is also not explicit in
the draft for ipv{4,6}hint and alpn.
For the "mandatory" key, a sensible ordering (ascending) is specified
and it is explicit that a key can only be present once in the set.
Cheers,
Pieter
--
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] FOSDEM 2020 DNS Developer Room Call for Participation
Hello DNSOP! tl;dr Please consider submitting a presentation for the DNS devroom at FOSDEM 2020. More details: Every year, developers from all over Europe (and some from farther away) meet in Brussels to discuss Open Source software and many other topics. After a successful and packed DNS devroom (track) at FOSDEM 2018 and 2019, we are happy to announce a half-day DNS devroom at FOSDEM 2020. As with the last years, we hope to host talks anywhere from hardcore protocol stuff, to practical sessions for programmers that are not directly involved with DNS but may have to deal with DNS in their day to day coding or system administrators responsible for DNS infrastructure. We have been allotted a room on Saturday 1 February 2020. We expect to schedule 30 minutes per talk, including questions, but if you need more or less time, we can discuss this. If you have something you’d like to share with your fellow developers, please head to pentabarf at https://penta.fosdem.org/submission/FOSDEM20. Examples of topics are measuring, monitoring, DNS libraries, anecdotes on how you’ve (ab)used the DNS, and group discussions of upcoming technologies. Here’s the 2019 schedule, for your inspiration: https://archive.fosdem.org/2019/schedule/track/dns/ . The deadline for submission is December 1st 2019. If you have a FOSDEM pentabarf account from a previous year, please use that account. Reach out to dns-devroom-mana...@fosdem.org if you run into any trouble. See you there! Cheers, The FOSDEM 2020 DNS Devroom organizers P.S. Apologies to those receiving multiple copies of these emails. -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoptions: draft-lhotka-dnsop-iana-class-type-yang
Hello DNSOP, On 7/15/19 10:00 PM, Benno Overeinder wrote: > This starts a Call for Adoption for: > draft-lhotka-dnsop-iana-class-type-yang I support adoption of this draft, the idea is non-controversial. I believe the comments that have been made can be worked out and I believe the YANG/NETCONF ecosystem can benefit from this document being published. Best regards, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new version of mixfr
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 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 and not reply with NOTIMPL. In a similar vein, unaware auths will respond with an NXDOMAIN or (more likely) a NODATA in that case. Best regards, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname
Hi Tim et al., On Thu, 11 May 2017 06:55:55 -0400 tjw ietf wrote: > This starts a Call for Adoption for: draft-hunt-dnsop-aname > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. I support the adoption of this draft by the working group. I have some reservations on the requirements for recursors in this draft, but this will be discussed at length I believe. > Please also indicate if you are willing to contribute text, review, etc. As Peter is a direct colleague of mine, I will not supply a review, but am willing to provide text. Best regards, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft for ALIAS/ANAME type
Hello Anthony, On Wed, 29 Mar 2017 08:51:50 -0500 Anthony Eden wrote: > https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ > > This draft describes the ALIAS/ANAME record (aka CNAME-flattening) > that numerous vendors and DNS providers are now supporting in > proprietary fashions. I hope that this draft will eventually lead to a > good mechanism for interop of ALIAS/ANAME records. First off, thank you for this. I would love to hear from current implementors of ALIAS/ANAME/CNAME-flattening what their ideas/critisisms are. This said, I have several comments after a first quick read of the document. There is no mention of the fact that ALIAS is mostly meant for zone apexes where other records MUST be present and a CNAME cannot exist. CNAMEs would cover non-apex usecases for ALIAS. I miss guidance what should happen when an ALIAS record is queried directly (would it be returned, should it be refused, should it be an empty response?). I miss words on the interaction between ALIAS records and other (mostly A and ) records on the same node. Section 3.1 "The server will respond with one or more A records", I fail to see why this cannot be zero or more. Am ALIAS target without A or records should yield an empty response from the authoritative server. "If the recursive query returns an NXDOMAIN response, then the authoritative name server MUST return an NXDOMAIN response as well.". If any other records exist (which is always the case for the apex), or if there are labels underneath the ALIAS'es name, the authoritative server cannot send out NXDOMAIN. Section 3.3 This section has 2 similar paragraphs, one with should and the other with MUST. Asking directly for a CNAME for a node that only has an ALIAS record should yield a response indicating that RRType does not exist at that node. Again, thank you for starting this draft. I support adoption of this draft in the dnsop WG to facilitate better interop between ALIAS/ANAME/CNAME-flattening implementors. Best regards, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-serve-stale
On Mon, 27 Mar 2017 18:19:09 -0400 Jared Mauch wrote: > I will note there are other implementations out there as well, such as in > unbound. serve-expired configuration directive is available there as well. I feel that the authors should attempt to describe the goal of the algorithm and suggest possible limits and describe pitfalls rather than describing the exact algorithm to use. This will allow implementers to come up with new and innovative algorithms based on continued measurements. I do support an adoption of such a draft in the WG. Best regards, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
