Re: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt

On Tue, 2 Jan 2024 at 07:34, zuop...@cnnic.cn wrote: >8 > This draft suggests a lightweight and backward-compatible mechanism to > mitigate the risk of these attacks. > > Any comments are welcome! > The proposal contains internal inconsistencies and contradictions which need to be

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

On Tue, 20 Jun 2023 at 22:20, Roy Arends wrote: >8 > > The change was from -03 to -04 and discussed in the WG IIRC. The specific > sentence your refer to was a lingering oversight in the changes from -03 to > -04. I have consulted many developers on this, and so far I had no push back. > > >

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

Correction Deleting that one sentence changes the meaning of the proposal from explicitly querying the authoritative server for the appropriate report channel to a dependence on authoritatives attaching an -(unsolicited) EDNS0 report channel option to each and every query.

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

On Tue, 20 Jun 2023 at 12:21, Roy Arends wrote: >8 > > On 20 Jun 2023, at 12:14, Willem Toorop wrote: >8 > > I have one nit. > > > > In the Example in section 4.2., a request still "includes an empty ENDS0 > > report channel". The third paragraph of that same section states something > >

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

On Tue, 20 Jun 2023 at 12:14, Willem Toorop wrote: >8 > In the Example in section 4.2., a request still "includes an empty ENDS0 > report channel". The third paragraph of that same section states > something similar: "As support for DNS error reporting was indicated by > a empty EDNS0 report

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

ay consist of multiple labels and is - concatenated as is, i.e. in DNS wire format. + * The list of non-null labels representing the query which is the + subject of the DNS error report. * The extended DNS error, presented as a decimal value, in a single DNS label. Regards D

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

like standard DNS messages, the question section, answer section, authority records section, and additional records sections are not present. The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) MUST be se

Re: [DNSOP] Call for Adoption: Structured Data for Filtered DNS

On Tue, 24 Jan 2023 at 19:28, Tim Wicinski wrote: >8 > One thing which concerns me is the updating of RFC8914. RFC8914 has only been > out a short while, and we're just starting to see deployment out in the world. It does seem distasteful to pile structured data into a field which RFC8914

Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on glue definition

On Thu, 3 Nov 2022 at 21:49, Benno Overeinder wrote: > >8 > > Q2. Definition of Glue provided by Duane Wessels on the DNSOP WG mailing > list: > > "Glue is non-authoritative data in a zone that is transmitted in the > additional section of a referral response on the basis that the

Re: [DNSOP] Representing DNS Messages in JSON (RFC 8427): ugly EDNS

EXTENDED-ERROR => ( INFO-CODE => 123, EXTRA-TEXT => "" ) ;; CLIENT-TAG => ( 7261776279746573 ) ;; SERVER-TAG => ( 7261776279746573 ) ;; UMBRELLA-IDENT => ( 7261776279746573 ) ;; DEVICEID => ( 7261776279746573 ) Dick Franks ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt

On Thu, 7 Apr 2022 at 19:44, Joe Abley wrote: > > On Apr 7, 2022, at 21:10, Paul Vixie > wrote: > > > but it seems to me you'd be better off with a zero-length option called > > SERIAL which if set in the query causes the SOA of the answer's zone to be > > added to the authority section

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt

On Thu, 7 Apr 2022 at 14:48, Paul Vixie wrote: > > because IXFR and NOTIFY and UPDATE use serial numbers, the DNS protocol > itself is aware of serial numbers. i hope that any recognition of > non-traditional serial numbers will be an optional addition to the > RRSERIAL response, and that if a

Re: [DNSOP] New Version Notification - draft-ietf-dnsop-svcb-https-06.txt

On Mon, 5 Jul 2021 at 03:11, Mark Andrews wrote: >8 > > Opaque key form isn’t subject to double parsing despite the hint6 having > commas in the presentation form. That’s about the only way you could be > seeing that difference. The opaque key form knows nothing about the > internal structure,

Re: [DNSOP] Fwd: New Version Notification - draft-ietf-dnsop-svcb-https-06.txt

Feedback on SVCB draft 06 as requested. On Mon, 28 Jun 2021 at 02:39, Tim Wicinski wrote: >8 > > The chairs would like the WG to review these changes, and give us some > feedback. 6.1. "alpn" and "no-default-alpn" The presentation "value" SHALL be a comma-separated list (Appendix A.1)

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

ke the issue go away. --Dick > > --Ben > > [1] > https://github.com/MikeBishop/dns-alt-svc/commit/5d3d651230de06adce10625d0dfb70ce8e938a39 > [2] https://github.com/MikeBishop/dns-alt-svc/pull/325/files > > On Sat, May 22, 2021 at 12:58 PM Dick Franks wrote: >> >>

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Sat, 22 May 2021 at 17:06, Paul Hoffman wrote: > > On May 22, 2021, at 1:58 AM, Dick Franks wrote: > > > Please find attached the promised words to resolve the conflict > > between current draft and RFC1035. > > > > This is presented as a context diff.

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

All, Please find attached the promised words to resolve the conflict between current draft and RFC1035. This is presented as a context diff. Dick Franks draft-ietf-dnsop-svcb-https.diff.gz Description: application/gzip

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

All, As part of a side discussion, I was admonished for my rather flippant approach to a significant security issue and failure to explain clearly how it manifests itself.. On Sun, 9 May 2021 at 13:01, Dick Franks wrote: >8 > > Pre-processing of '\\,' into the RFC1035

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Mon, 10 May 2021 at 00:28, Paul Hoffman wrote: > > On May 9, 2021, at 11:26 AM, Paul Wouters wrote: > > This is all pretty terrible. I agree with Tim that we should not inflict > > this onto the users. Or perhaps we can already pre-allocate some CVE > > numbers for the security issues this

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Mon, 10 May 2021 at 00:42, 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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Fri, 7 May 2021 at 16:52, Paul Hoffman wrote: > > 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

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

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. >&g

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, 4 May 2021 at 21:18, Ben Schwartz wrote: > > On Tue, May 4, 2021 at 12:09 PM Dick Franks wrote: >> >> The brutal reality is that the char-string parser has already >> obliterated the distinction between escaped and unescaped commas >> before the value-l

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

they "couldn’t >> re-use their string parsers" (despite no existing parser supporting >> key=“value”) >> so now we have to double escape backslashes. I very much feel that this is >> tail >> wagging the dog. >> >> > On 3 May 2021, at 01:25,

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

5c5c6f6f5c03626172026832 ) the escaped escape characters being inserted as uninterpreted text per RFC1035. Dick Franks ___ 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

On Fri, 19 Mar 2021 at 10:15, Willem Toorop wrote: >8 > > > The Net::DNS perl library does have parsing and printing of SVCB and > HTTPS based on draft-ietf-dnsop-svcb-https-01 since version 1.26 > (released on August 6, 2020). @Dick, what is your position on this? Change of name only affects

Re: [DNSOP] DNS Error Reporting

[Section 5] o REPORTING AGENT DOMAIN, a Domain name [RFC8499 <https://tools.ietf.org/html/rfc8499>]. should read: o REPORTING AGENT DOMAIN, a Domain name [RFC8499 <https://tools.ietf.org/html/rfc8499>] in the format prescribed by [RFC1035 <https://tools.ietf.org/html/rf

Re: [DNSOP] HTTPS and SVBC key names.

HTTPS and SVCB in Net::DNS 1.25_01 coming soon to a CPAN server near you. Documentation needs more attention. Thanks for the helpful comments, most of which are in there in some form or another. --Dick ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS

On Thu, 23 Jul 2020 at 08:33, Mark Andrews wrote: > On 23 Jul 2020, at 16:51, Petr Špaček wrote: > >8 > > > I'm not native English speaker and I personally find confusing that > sequence of characters "mandatory" is used as verb and also as name of the > key. "optional mandatory" sounds like

Re: [DNSOP] HTTPS and SVBC key names.

On Mon, 20 Jul 2020 at 22:54, Ben Schwartz wrote: The unknown-key format is designed more for authoring than reading. As an > author, it works somewhat better than your example. For instance, your > key1 could be written as > > key1=\005h3-29\005h3-28\005h3-27\002h2 > It is not as easy as you

Re: [DNSOP] HTTPS and SVBC key names.

On Tue, 21 Jul 2020 at 00:25, Mark Andrews wrote: > > IMHO, tarted up RFC3597 format is easier to read. > > Well the presentation form clearly is designed for printable ASCII to be > rendered as ASCII. > Except for the inconvenient fact that Net::DNS also works on OS390 which speaks EBCDIC.

Re: [DNSOP] HTTPS and SVBC key names.

On Thu, 16 Jul 2020 at 21:17, Ben Schwartz wrote: > > Quotes are optional, as with . Quotes are only required > if the value contains whitespace. > I was trying to establish if the quotes indicated the data type. Clearly not. > The presentation format is optimized for humans and the wire

Re: [DNSOP] HTTPS and SVBC key names.

On Thu, 16 Jul 2020 at 13:31, Ben Schwartz wrote: > On Thu, Jul 16, 2020, 4:07 AM Dick Franks wrote: > >> >> Beefed-up example from 5.3, where we know neither the key name nor how to >> interpret the value: >> >> foosvc.example.net. 3600 IN SVCB

Re: [DNSOP] HTTPS and SVBC key names.

order in the presentation format? Dick Franks ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ie

Re: [DNSOP] HTTPS SVCB no service available signal.

On Thu, 9 Jul 2020 at 23:18, Joe Abley wrote: > On Jul 9, 2020, at 17:18, Ben Schwartz > wrote: > > This seems like a reasonable idea to me. We should be able to incorporate > this for the next draft revision. > > > I guess I'll mention that when I suggested MNAME=. to indicate that a zone >

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

f that apply? The algorithm in this case is specified by another standards organisation and is what it is. Community review did not find the incorrect test parameters in RFC5832 / GOST R34.10-2001. --Dick Franks > ___ > DNSOP mailing list >

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

-2012 having already passed, algorithm 12 should be marked N in the DNSSEC Algorithm Numbers <http://www.iana.org/assignments/dns-sec-alg-numbers> registry. Dick Franks > ___ > DNSOP mailing list > DNSOP@ietf

Re: [DNSOP] On Powerbind

On Fri, 17 Apr 2020 at 10:27, Olaf Kolkman wrote: > Looking for this: > https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml ? > I guess we were. The extraneous bits appear to be remnants of DNSKEY's previous life as a KEY RR, defined in RFC2535 3.1.2, and presumably now obsolete.

Re: [DNSOP] On Powerbind

; } # Bit 6 must be set to 0 bit 7 must be set to 1 if ( ($keyrr->{"flags"} & hex("0x300")) != hex("0x100")){ croak "\nCreating a DS record for a key with flags 6 and 7 not set ". "0 and 1 respective

Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones

Response in line On Mon, 9 Mar 2020 at 07:20, Mark Andrews wrote: >8 > > [1.2 para 1] > > > > ... The procedures for digest calculation and DNSSEC > > signing are similar (i.e., both require the same ordering of RRs) and > > can be done in parallel. > > > > There is no requirement for

Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones

the digest into the placeholder ZONEMD. Repeat for each digest if multiple digests are to be published. If the zone is signed with DNSSEC, the RRSIG record covering the ZONEMD RRSet MUST then be added or updated. Dick Franks ___

Re: [DNSOP] Unknown DNS RDATA type presentation syntax vs. e.g. TXT records?

On Mon, 10 Feb 2020 at 16:19, Tony Finch wrote: >8 > When I was working out how a SHA-1 attack could work with TXT records, > (https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html) > one of the problems was that the collision blocks in the best attack so > far are 588 bytes, which is too big

Re: [DNSOP] Fwd: [Editorial Errata Reported] RFC1035 (5915)

On Mon, 23 Dec 2019 at 22:01, Ray Bellis wrote: > > On 20/12/2019 15:08, Bob Harold wrote: > > > But if we are updating it, could we consider a better word than > > "forward" ? Actually "backward" would be correct, although I prefer > > "from the back to the front" as used elsewhere. > > It's

Re: [DNSOP] Deprecating the status opcode

IMHO, not worth the effort Dick Franks On Sun, 19 May 2019 at 18:31, tjw ietf wrote: > > Can we like this draft *and* a RFC cleanup of 1034/1035? > > Though watching tcpm do this for 793 has been disheartening > > From my high tech gadget > >

Re: [DNSOP] Call for Adoption: draft-wessels-dns-zone-digest

Assuming that the draft is adopted, I am willing to work on it and contribute new text. Dick On Sun, 10 Mar 2019 at 14:31, Tim Wicinski wrote: > > The chairs feel the document has been updated to address > several issues raised from the last meeting, including >

Re: [DNSOP] RFC 2845bis and HMAC-MD5

On Thu, 14 Mar 2019 at 15:09, Tony Finch wrote: > Martin Hoffmann wrote: > > > > As such, I would like to propose to move HMAC-MD5 to optional and only > > retain SHA-1 and SHA-256 as mandatory. > > That seems sensible. There should at the very least be a reference to > RFC6151, Updated

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

On Fri, 8 Mar 2019 at 03:58, Paul Wouters wrote: 8< You are suggesting to introduce an option code point to convey blobs in > DNS. So different parties can send and receive blobs. You think or hope > that these parties will interpret this blob the same. But you have no > guarantee this is true.

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

On Tue, 5 Mar 2019 at 09:27, Ray Bellis wrote: 8< Stretching the analogy to BGP communities slightly (the authors had > already discussed this internally when working on the draft, and Wes has > made that comparison too): > > Folks *could* have decided to use some unassigned BGP Path attribute

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

On Tue, 5 Mar 2019 at 08:13, Ray Bellis wrote: > > > On 04/03/2019 23:03, Wes Hardaker wrote: > > > Hmmm.. very interesting idea, but I'm having a hard time seeing how > > this will be used in the real world in a scalable and interoperable > > way. > > The use cases on the open internet are

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

On Tue, 5 Mar 2019 at 00:45, Mark Andrews wrote: 8< Presumably you won’t get back a server tag and you can log that. > Not always. The spec does not require the server to return a server tag in response to a client tag. However, a server tag may only be returned in response to a request

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

On Mon, 4 Mar 2019 at 23:43, Wes Hardaker wrote: > Dick Franks writes: > > > As the man said, "[semantics are] determined by bi-lateral agreement". > > If the counter-party decides to do something different, it has > repudiated the > > agreement. > >

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

On Mon, 4 Mar 2019 at 23:03, Wes Hardaker wrote: > Ray Bellis writes: > > > This new draft describes a way for clients and servers to exchange a > > limited amount of information where the semantics of that information > > are completely unspecified, and therefore determined by bi-lateral > >

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

On Thu, 21 Feb 2019 at 12:25, Tony Finch wrote: > Mark Andrews wrote: > > > On 21 Feb 2019, at 6:30 am, Tony Finch wrote: > > > > > > Does it need to be per-record? Why not GC the whole RRset? > > > > Because there are scenarios where you do want to GC as single > > record from the RRset. AD

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

On Wed, 20 Feb 2019 at 11:27, Petr Špaček wrote: 8< > Yet another code propodsl: > * answer with stale data > >The resolver was unable to resolve answer within its time limits and >decided to answer with stale data instead of answering with an error. >This is typically caused by

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

On Wed, 20 Feb 2019 at 12:36, Tony Finch wrote: > Dick Franks wrote: > > > > Unsigned 32 bit RRSIG time is good for travel until 7th February 2106. > > No, it lasts indefinitely. It covers +/- 68 years relative to current > POSIX time using serial number arithmet

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

On Tue, 19 Feb 2019 at 21:27, Tim Wattenberg wrote: > 8< > RRSIG, SIG, TKEY (32 bits with serial number arithmetic relative to now) > > > > TSIG (48 bits) > > thanks for bringing up this point again. I was aware of the way RRSIG > presents time but thanks for pointing us to TSIG – I hadn’t

Re: [DNSOP] Implementations of extended error?

There is not yet a proper IANA allocated option code for this. Might I suggest that all interested parties settle on 65015 from the local/experimental block until the real thing arrives. Dick Franks On Fri, 1 Feb 2019 at 17:33, Wes Hardaker wrote: > > Folks,

Re: [DNSOP] TSIG - add presentation format for humans.

On Wed, 21 Nov 2018 at 21:31, Mark Andrews wrote: > > -- > Net::DNS has offered this information for many years in the form of comments, which avoids a disaster if inadvertently ingested by a parser. $packet->print; ;; HEADER SECTION ;;id = 51343 ;;qr = 0aa = 0tc = 0rd = 0

Re: [DNSOP] I-D Action: draft-ietf-dnsop-algorithm-update-03.txt

On Tue, 23 Oct 2018 at 19:34, Tim Wicinski wrote: The WGLC has completed and we were waiting on the authors on addressing all > comments and updating their document. > The chairs feel this is ready to proceed. > Just spotted a fumble with document references in section 3.1 which will need to be

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-terminology-bis-11

Some of this lack of precision is spread about by much-loved DNS tools. ; <<>> DiG 9.11.4-RedHat-9.11.4-4.fc28 <<>> @b.root-servers.net . -t NS ; (2 servers found) ;; global options: +cmd ;; Got answer: <<< ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37483 ;;

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

On 12 July 2018 at 02:58, Dave Crocker wrote: > On 7/6/2018 8:22 AM, Stephane Bortzmeyer wrote: > >> Editorial: I would prefer all occurrences of "right-most" to be >> replaced by "most general", to emphasize that it is not the position >> which matters, it is the closeness to the root. >> >>

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

On 10 July 2018 at 15:32, Dave Crocker wrote: > On 7/9/2018 2:35 PM, Dick Franks wrote: >8 > >> >> If a public specification calls for the use of an >> underscore-prefixed domain name, >> the underscored name closest to the root MUST be entered into this &

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

On 9 July 2018 at 19:48, Dave Crocker wrote: >8 > Does this cause anyone intolerable heart-burn? If it does, please at > least explain but preferably offer something better. > I do not suffer from intolerable heart-burn but happy to offer: If a public specification calls for the use of an

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

On 3 July 2018 at 16:40, Joe Abley wrote: > On 3 Jul 2018, at 09:11, Matthew Pounsett wrote: > > > This is not a complete review of the latest revision.. I'm hoping to get > to that in a day or two. But I've got a question about whether something > should be added to the document.. > > > > A

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

On 2 July 2018 at 00:03, Paul Hoffman wrote >8 > Well, RFC 1035 *does* say that it is in ASCII, whether we like that or not. Perhaps we need to remind ourselves what RFC1035 actually *does* say. ASCII is mentioned in three places only: 2.3.3 para 1, initially about case-insensitive

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

le.tld". [RFC1035] defines a numerical representation that may be used to display octets for which there is no corresponding ASCII printable character. Dick Franks On 22 June 2018 at 21:01, Suzanne Woolf wrote: > Colleagues, > > This begins the

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

On 26 March 2018 at 22:36, Paul Vixie wrote: > i've had my symbolics 3640 online quite a bit in the last 30 years, and it > still makes WKS queries, and i have used WKS responses to control it. the > software still works as well as it was designed to do, but the vendor is >

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

On 26 March 2018 at 16:42, Paul Vixie wrote: > > > Ondřej Surý wrote: > >> No, I am claiming that no current Internet standard is using those >> records and they were already marked as EXPERIMENTAL or OBSOLETE 30 >> years ago. >> > > the original specification of these RR types

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

On 26 March 2018 at 14:39, Tony Finch wrote: > Evan Hunt wrote: > > > > These RR types have text representations and wire format representations, > > which from a complexity standpoint seem quite harmless to implement. > There > > are the old annoying rules about

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

On 23 March 2018 at 12:11, Ondřej Surý wrote: > > this is a first attempt to start reducing the load on DNS Implementors and > actually remove the stuff from DNS that’s not used and not needed anymore. > I have no quarrel with the overall effect of this proposal, but the

Re: [DNSOP] Terminology question: split DNS

On 19 March 2018 at 21:30, Steve Crocker wrote: > I haven't been following the current thread but I have encountered this > topic before and I have thought about the implications for DNSSEC. > > The terminology of "split DNS" -- and equivalently "split horizon DNS" -- > is,

Re: [DNSOP] Clarifying referrals (#35)

On 29 November 2017 at 12:17, Andrew Sullivan wrote: > On Wed, Nov 29, 2017 at 01:14:13PM +1100, Mark Andrews wrote: > > When the CNAME refers to a name that is out of zone and the target zone > is below > > a zone that the server serves you will have CNAME (DNAME) +

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

On 27 June 2017 at 18:10, Jan Včelák wrote: >8 There is plenty other alternative ways to express DS DELETE request. > But I would prefer accepting this simple erratum rather than > researching all the other options (which we should have done when > revising the drafts of this

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

On 26 June 2017 at 15:30, Matthijs Mekking <matth...@pletterpet.nl> wrote: > > > On 26-06-17 13:29, Dick Franks wrote: > > You misunderstood: Variable length in octets, but not variable in number > of RDATA elements I did. Am I correct in thinking that you want som

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

On 26 June 2017 at 09:39, Matthijs Mekking wrote: I raised the specific issue because the to be RFC 8078 was going to change > the CDS and CDNSKEY RDATA format from a fixed length RDATA to a variable > length: In case of the DELETE operation, the Digest in presentation

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

On 26 June 2017 at 10:59, Jan Včelák wrote: >8 > > The implementers should be careful and avoid the trouble. In this > sense, I think parent zone should accept both zero-length and one-byte > long digests/keys as a request to remove the DS. > Exactly! The _only_ way to

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

On 25 June 2017 at 20:54, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > On 24 Jun 2017, at 6:25, Dick Franks wrote: > > > In each case, > > > > CDS 0 0 0 0 > > > > CDNSKEY 0 3 0 0 > > > > the final "0" is a conventional

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

On 24 June 2017 at 16:45, Ondřej Caletka wrote: >8 The result that made it to the RFC is that there should be indeed one > byte with value of 00 in the Digest/Public key field instead of no data > at all. That does not appear to be the position at all. RFC8078

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

Comments in line below On 23 June 2017 at 12:37, Ólafur Guðmundsson wrote: > The errata is correct. > I beg to disagree. In each case, CDS 0 0 0 0 CDNSKEY 0 3 0 0 the final "0" is a conventional token representing a zero-length key field. In neither

Re: [DNSOP] search for reference

HMAC-SHA512 165 Dick Franks On 30 December 2016 at 11:20, A. Schulze <s...@andreasschulze.de> wrote: > > Mukund Sivaraman: > > TSIG uses DNS names for encoding the algorithm type. >> > I didn't ex

Re: [DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt

My mistake. Apologies. I also had draft-wouters-sury-dnsop-algorithm-update-02 on screen. That has the registry table with same TBDs. Starting at 04:30 dulls the brain. Dick Franks On 15 November 2016 at 17:05, Ondřej Surý <ondrej.s...@nic.cz> wrote: >

Re: [DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt

Ondrej The document calls up two TBD code points for the EDDSA algorithms, but the IANA Considerations section places no action on IANA to assign these and add them to the registry. Other than that, seems ok. Dick Franks On 14 November 2016 at 23:22, Ondřej Surý

Re: [DNSOP] Erratra rejection

On 11 March 2016 at 17:47, Robert Edmonds <edmo...@mycre.ws> wrote: > Dick Franks wrote: > > There is no need to resort to doctrinal arguments about MUST/SHOULD, or > > imagine that the RFC6844 tail can wag the RFC1035 dog. > > > > Mark A's objection really p

Re: [DNSOP] Erratra rejection

the canonical format prescribed by section 5.1.1 The same form of words, or at least compatible words, should be used in both places. RFC6844 offers no justification for case folding, so specifying exact matching would make the whole issue go away. Dick Franks On 10 March

Re: [DNSOP] Setting the AD bit in the query changes whether you get the AD bit in the response?

in Section 3.2.3 of [RFC4035], and the request contained either a set DO bit or a set AD bit. -- Dick Franks ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Setting the AD bit in the query changes whether you get the AD bit in the response?

oth meets the conditions listed in Section 3.2.3 of [RFC4035], and the request contained either a set DO bit or a set AD bit. -- Dick Franks ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Order of DNS records...

bious sample. Dick Franks On 11 January 2016 at 21:20, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > Interesting: it sends the signature before the SOA (and it breaks at > least one DNS program - one of mine, shame): > > % dig @ns02.one.com. SOA masters-

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

Dick Franks On 1 October 2015 at 11:12, Shane Kerr <sh...@time-travellers.org> wrote: > > In the case where people just want to reduce the damage of ANY queries > in reflection attacks, I quite like the PowerDNS option of forcing ANY > queries to TCP v

Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?

Next release of Net::DNS::SEC will support ECDSA and ECC-GOST Dick Franks On 19 January 2015 at 15:17, Warren Kumari war...@kumari.net wrote: On Monday, January 19, 2015, Francis Dupont francis.dup...@fdupont.fr wrote: In your previous mail you wrote

Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?

Next release of Net::DNS::SEC will support ECDSA and ECC-GOST Dick Franks On 19 January 2015 at 15:17, Warren Kumari war...@kumari.net wrote: On Monday, January 19, 2015, Francis Dupont francis.dup...@fdupont.fr wrote: In your previous mail you wrote

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

On 22 September 2014 12:27, Tony Finch d...@dotat.at wrote: Dick Franks rwfra...@acm.org wrote: On 22 September 2014 11:03, Tony Finch d...@dotat.at wrote: (1) Master-only. The master observes an ANAME record at the apex of a zone it loads and uses it to periodically refresh

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

On 21 September 2014 19:14, bert hubert bert.hub...@netherlabs.nl wrote: On Sun, Sep 21, 2014 at 08:13:46AM -0700, Paul Hoffman wrote: PS: the above is currently not yet supported for DNSSEC domains! Can you say (much) more about that aside? Does it mean that the server An interesting

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

Mark, Surely, something stronger than a reminder is appropriate. For a mission-critical requirement, this needs to be an explicit and unambiguous request: This document directs IANA to create insecure delegations for the listed zones. Dick On 14 August

Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B)

On 11 April 2012 14:48, Matthijs Mekking matth...@nlnetlabs.nl wrote: On 04/05/2012 12:48 AM, Alfred � wrote: | o Signature validity period The time interval during which a | signature is valid. It starts at the (absolute) time specified in | the signature inception field of