[DNSOP] Publication has been requested for draft-ietf-dnsop-rfc7816bis-09
Tim Wicinski has requested publication of draft-ietf-dnsop-rfc7816bis-09 as Internet Standard on behalf of the DNSOP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
On Mon, 27 Jan 2020 at 10:09, Hugo Salgado wrote: > > Dear DNSOPers, as an operator I tend to have this need to couple > an answer for a query to an auth server, with the actual "SOA zone > version" used. So I think it'll be valuable to have an EDNS option > for it. I also missed this the first time around. Mauricio brought it up during the OARC workshop last night; I think it's a very good idea, and the WG should adopt it. There are many occasions in the past where this would have been helpful in debugging, and I'm sure there will be many more in the future. I haven't read this in detail yet, but I will happily provide reviews if the WG adopts it. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
Seems like a good idea to me. I think the WG should adopt it. Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Mon, Jan 27, 2020 at 10:09 AM Hugo Salgado wrote: > > Dear DNSOPers, as an operator I tend to have this need to couple > an answer for a query to an auth server, with the actual "SOA zone > version" used. So I think it'll be valuable to have an EDNS option > for it. > > Here I'm proposing it with this new draft. The 'camel index' for > its implementation/hack/proof-of-concept is about 37 lines in > NSD 4.1 (more details in Appendix A). > > I've asked some operators and they see value on it. Is there any > support for adoption in DNSOP? > > - > Name: draft-salgado-rrserial > Revision: 01 > Title: The "RRSERIAL" EDNS option for the SOA serial of a RR's zone > Document date: 2020-01-27 > Group: Individual Submission > Pages: 5 > URL: > https://www.ietf.org/internet-drafts/draft-salgado-rrserial-01.txt > Status: https://datatracker.ietf.org/doc/draft-salgado-rrserial/ > Htmlized: https://tools.ietf.org/html/draft-salgado-rrserial-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-salgado-rrserial > Diff: https://www.ietf.org/rfcdiff?url2=draft-salgado-rrserial-01 > > Abstract: >The "RRSERIAL" EDNS option allows a DNS querier to ask a DNS >authoritative server to add a EDNS option in the answer of such query >with the SOA serial number field of the origin zone which contains >the answered resource record. > >This "RRSERIAL" data allows to debug problems and diagnosis by >helping to recognize the origin of an answer, associating this answer >with a respective zone version. > - > > Best, > > Hugo Salgado > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
On Fri, May 7, 2021 at 10:03 AM Joe Abley wrote: > Hi Hugo, > > On 7 May 2021, at 12:47, Hugo Salgado wrote: > > > I'll upload a new version to revive it, and ask for a slot > > in IETF111 for further discussion! > > Just to add my voice to the chorus, I missed this the first time around so > thanks, Mauricio, for mentioning it. > > I haven't read the draft in detail but I do like the idea and could think > of many times this would have been useful for data collection, debugging, > etc. > > I concur with everything Joe wrote. So, very much in favor of this, thanks for doing this. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Martin Duke's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-dnsop-nsec-ttl-04: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ -- COMMENT: -- No need for a response on these: Please expand TTL and SOA on first use. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
On 7 May 2021, at 13:39, John Levine wrote: > It appears that Hugo Salgado said: >> -=-=-=-=-=- >> >> I'll upload a new version to revive it, and ask for a slot >> in IETF111 for further discussion! > > It looks like it's worth considering, but I also wonder how > relevant it is for DNS servers that don't use AXFR/IXFR and SOA > serial numbers to keep versions in sync. SOA serial numbers are definitely useful for the apex SOA/IN queries that are prerequisites to zone transfers. However, they're also really useful information for any dynamic zone that you're trying to troubleshoot. Successive queries are not necessarily going to return matching information. By analogy, you can send a query to a nameserver and get a troublesome response, and debug with a HOSTNAME.BIND/CH/TXT query to see what server it was. But for a nameserver provisioned with anycast or as part of a cluster, those data points are not necessarily going to match, which is why NSID is good. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
On Fri, May 07, 2021 at 01:39:56PM -0400, John Levine wrote: > It appears that Hugo Salgado said: > >-=-=-=-=-=- > > > >I'll upload a new version to revive it, and ask for a slot > >in IETF111 for further discussion! > > It looks like it's worth considering, but I also wonder how > relevant it is for DNS servers that don't use AXFR/IXFR and SOA > serial numbers to keep versions in sync. In that case not much, but for many that uses in-band zone transfer mechanisms it is very relevant. Specially in the case that the serial in a zone is time deterministic. Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
It appears that Hugo Salgado said: >-=-=-=-=-=- > >I'll upload a new version to revive it, and ask for a slot >in IETF111 for further discussion! It looks like it's worth considering, but I also wonder how relevant it is for DNS servers that don't use AXFR/IXFR and SOA serial numbers to keep versions in sync. I put serial numnbers in my zones but in fact my servers use rsync from a hidden master so the serials don't tell you much. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
Hi Hugo, On 7 May 2021, at 12:47, Hugo Salgado wrote: > I'll upload a new version to revive it, and ask for a slot > in IETF111 for further discussion! Just to add my voice to the chorus, I missed this the first time around so thanks, Mauricio, for mentioning it. I haven't read the draft in detail but I do like the idea and could think of many times this would have been useful for data collection, debugging, etc. Joe signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
I'll upload a new version to revive it, and ask for a slot in IETF111 for further discussion! Thanks, Hugo On 22:02 06/05, Mauricio Vergara Ereche wrote: > Hi Hugo, > > I just want to bring back to life this topic as it solves an issue that > several operators (like me) seem to be in need to solve while debugging > issues. > > Mauricio > > On Mon, Jan 27, 2020 at 7:09 AM Hugo Salgado wrote: > > > Dear DNSOPers, as an operator I tend to have this need to couple > > an answer for a query to an auth server, with the actual "SOA zone > > version" used. So I think it'll be valuable to have an EDNS option > > for it. > > > > Here I'm proposing it with this new draft. The 'camel index' for > > its implementation/hack/proof-of-concept is about 37 lines in > > NSD 4.1 (more details in Appendix A). > > > > I've asked some operators and they see value on it. Is there any > > support for adoption in DNSOP? > > > > - > > Name: draft-salgado-rrserial > > Revision: 01 > > Title: The "RRSERIAL" EDNS option for the SOA serial of a RR's > > zone > > Document date: 2020-01-27 > > Group: Individual Submission > > Pages: 5 > > URL: > > https://www.ietf.org/internet-drafts/draft-salgado-rrserial-01.txt > > Status: https://datatracker.ietf.org/doc/draft-salgado-rrserial/ > > Htmlized: https://tools.ietf.org/html/draft-salgado-rrserial-01 > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-salgado-rrserial > > Diff: > > https://www.ietf.org/rfcdiff?url2=draft-salgado-rrserial-01 > > > > Abstract: > >The "RRSERIAL" EDNS option allows a DNS querier to ask a DNS > >authoritative server to add a EDNS option in the answer of such query > >with the SOA serial number field of the origin zone which contains > >the answered resource record. > > > >This "RRSERIAL" data allows to debug problems and diagnosis by > >helping to recognize the origin of an answer, associating this answer > >with a respective zone version. > > - > > > > Best, > > > > Hugo Salgado > > > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > > -- > Mauricio Vergara Ereche > keybase.io/mave signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Publication has been requested for draft-ietf-dnsop-iana-class-type-yang-02
Benno Overeinder has requested publication of draft-ietf-dnsop-iana-class-type-yang-02 as Proposed Standard on behalf of the DNSOP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ ___ 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
On May 7, 2021, at 3:21 AM, Pieter Lexis wrote:
> 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.
Pieter has a point here: to parse correctly, you need a two-step (or two-level)
process. The *only* way to prevent that in the spec would be to say that commas
are forbidden in parameter values. However, even if the spec said that,
someone would mess up and put a comma in a parameter value, and then different
parsers will yield different values based on whether or not they took that
shortcut.
Escaping is hard.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
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
I was rethinking my initial concerns, and needed to talk it out with others. After going back over it with folks smarter than myself, it's more obvious to me that when the need for escaping inputs will be more of an exception. My concern is focused not so much on implementers (sorry) but the operators and engineers who will be the ones inserting these records into zone files. I do however want to have the presentation format examples be full DNS records, and not just RDATA. In the followinbg section in on failure cases, DNS records are used: example.com. SVCB 1 foo.example.com. mandatory The test vectors should be the same. tim On Fri, May 7, 2021 at 9:19 AM Dick Franks wrote: > On Fri, 7 May 2021 at 11:21, Pieter Lexis > wrote: > > > >8 > > > > 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. > > Tim W. pointed out earlier in this thread that "those writing zone > contents" are the majority stakeholders and rarely familiar with the > finer points of DNS. > If we are inflicting confusion on these people by departing from > standard and well-understood character escapes for no other reason > than the convenience of developers, then we have our priorities > seriously wrong. > > > --Dick > ___ 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
On Fri, 7 May 2021 at 11:21, Pieter Lexis wrote: > >8 > > 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. Tim W. pointed out earlier in this thread that "those writing zone contents" are the majority stakeholders and rarely familiar with the finer points of DNS. If we are inflicting confusion on these people by departing from standard and well-understood character escapes for no other reason than the convenience of developers, then we have our priorities seriously wrong. --Dick ___ 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] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Hi Dick, Ben,
I'm the (new) developer at NLNet Labs who implemented SVCB in NSD. While
I have no strong opinion on the double escaping matter, I will pitch in
that NSD currently adheres to the draft (as far as I'm aware).
Best,
Tom
On 2021-05-06 22:16, 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:
But that is precisely what you are NOT doing.
You have assigned a special significance to the character sequence
"\\," contrary to RFC1035.
The language of RFC1035 is crystal clear that an escaped character is
parsed as plain text, independently, without regard to context, and
that any special meaning does not apply.
Strict application of the RFC1035 rules causes string "...\\,..."
to be equivalent to "...\092,...".
I'm not sure what you're describing. Those two inputs are universally
equivalent in zone files under the current draft. They are both
reduced to {'\', '"'} by char-string parsing, which is applied
uniformly and without modification to all SvcParamValues.
... and the '\' without any special meaning fails to protect the comma
from the attention of the argument splitter.
Each SvcParamValue has its own input format. For some SvcParamValues,
'\' and ',' may not be allowed characters. For others, they may be
ordinary characters to be copied into the output, or they may have
special significance.
... and I might, or might not, have a boiled egg for breakfast!
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.
The "value-list" format is a bit like a (much simpler) cousin of the
SPF macro language (https://tools.ietf.org/html/rfc7208#section-7.1).
In both cases, the char-string decoder's output contains embedded
commands that allow the next processing stage to distinguish between
delimiters (comma and space, respectively) and escaped delimiters ("\,"
and "%_", respectively).
That is no justification at all. SPF people can do whatever they
like within the arguments of a TXT record.
--Dick
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
