Re: [DNSOP] zonemd/xhash versus nothing new
On Jul 30, 2018, at 5:03 PM, Wes Hardaker wrote: >> I think the use for non-root zones is quite a different use case, I don’t. >> so if >> I ignore that, we are looking at specifically the root zone only. > > Please don't ignore that. We really do ourselves a disservice when we > design a solution that only works for singular or minimal instances. > This is beneficial to more than just the root zone. +1 I don’t think the benefits of mirroring a zone into a resolver is limited to the root. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zonemd/xhash versus nothing new
Paul Wouters writes: > What I see is that: > > We are looking at a way to distribute the root zone > maybe this is also useful for non-root zones, so the method was sort > of made to apply generically. > I think the use for non-root zones is quite a different use case, so if > I ignore that, we are looking at specifically the root zone only. Please don't ignore that. We really do ourselves a disservice when we design a solution that only works for singular or minimal instances. This is beneficial to more than just the root zone. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
Tim Wicinski writes: > The draft states in the Motivation section: > > "The motivation and design of this protocol enhancement is tied to the > DNS root zone [InterNIC]." That may be a motivation, but as a prospective user I want to use it for much more. My LocalRoot server is already going to be serving 3 zones, and I have plans for many more. It would be helpful to know that on the distribution side of things that I had indeed grabbed an authentic source before sending it off to all the resolvers that want to pre-cache a random zone X. Be careful that we don't collectively interpret the sentence you quote as meaning 'this is only useful for the root zone' just because that was the original motivation. In fact, I'd even argue to remove that sentence if it's causing such confusion. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Incremental zone hash - XHASH
Paul Wouters writes: > That leaves glue and NS, but there is a reason those aren't signed, > and any attacker shouldn't get anything out of that by modifying it. Yes, the glue isn't authoritative and thus not signed by DNSSEC. But, if you're transferring a zone from an original source to any secondary server that is redistributing the contents, then modification by an attacker can certainly do damage (though with fully deployed DNSSEC, it may be only a DOS; though without fully deployed it's much worse, and we're a long way from fully deployed on both ends). The question of need comes down to: regardless of how it's done, do we need a global zone data signature across the entire set of distributed data that survives multiple distribution hops. From the perspective of wanting to distribute data across a multitude of mechanisms (including DNS but all git, bittorrent, http, and Warren's dirty napkin), then there is value to having a verifiable checksum. That's why software packages are distributed in the same way: verify that what you got is authentic before using it. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
On 30 Jul 2018, at 16:12, Evan Hunt wrote: On Mon, Jul 30, 2018 at 03:44:11PM -0700, Paul Hoffman wrote: I am still mystified about the scenario in which a malicious zone operator creates two zone files with the same ZONEMD hash, one with the right set of addresses for unsigned child zones, and a different one with one of more of those child zones with wrong addresses plus enough other kruft to make the colliding hashes match. In what world is that attack more likely than just not using ZONEMD? I don't think the imagined attack involves a zone operator creating two zones. It would be a zone operating creating one zone, with a legitimate and validly signed ZONEMD, and then someone else creating a fake version of the zone in which all the signed rrsets still validate, and the ZONEMD still matches, but the unsigned parts have been mucked with. But that can't happen with any of the hash algorithms allowed by the draft. What you are describing is a second preimage attack, and no modern hash algorithm (not even MD5!) has any known second preimage weaknesses. The bit that started this thread was a concern about collision attacks. Collision attacks can only be mounted by the person who creates the hash, by creating two messages that both have the same hash. The suggestion was to not allow hash algorithms that had known collision resistance reductions (such as MD5 and SHA1), which is fine in general. However, as people went on and on about how to make further changes to the RRtype, I questioned what collision attack they were thinking of. Adding an RR count does make that attack more expensive. I'm not sure it makes enough difference to be worthwhile. Exactly. Another imagined attack is someone trying to dump terabytes on you when initiate the zone transfer. An RR count could help with that, if you looked it up before starting the transfer. See above. If you are blindly accepting terabytes of data from a trusted source, you have other problems. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
On Mon, Jul 30, 2018 at 03:44:11PM -0700, Paul Hoffman wrote: > I am still mystified about the scenario in which a malicious zone > operator creates two zone files with the same ZONEMD hash, one with the > right set of addresses for unsigned child zones, and a different one > with one of more of those child zones with wrong addresses plus enough > other kruft to make the colliding hashes match. In what world is that > attack more likely than just not using ZONEMD? I don't think the imagined attack involves a zone operator creating two zones. It would be a zone operating creating one zone, with a legitimate and validly signed ZONEMD, and then someone else creating a fake version of the zone in which all the signed rrsets still validate, and the ZONEMD still matches, but the unsigned parts have been mucked with. Adding an RR count does make that attack more expensive. I'm not sure it makes enough difference to be worthwhile. Another imagined attack is someone trying to dump terabytes on you when initiate the zone transfer. An RR count could help with that, if you looked it up before starting the transfer. (For the record, I neither favor nor oppose the idea. I don't see much benefit, but I also don't see much cost.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
On 30 Jul 2018, at 14:44, Wessels, Duane wrote: While I wouldn't necessarily be opposed to having an RR count field of some kind if there is good reason to have it, my preference would be to omit it and keep the record simpler. I am still mystified about the scenario in which a malicious zone operator creates two zone files with the same ZONEMD hash, one with the right set of addresses for unsigned child zones, and a different one with one of more of those child zones with wrong addresses plus enough other kruft to make the colliding hashes match. In what world is that attack more likely than just not using ZONEMD? And, even if it is possible to imagine that, requiring a hash function that has no collision attacks (like SHA-256) would suffice. Adding a RR count field would only make the malicious zone owner's attack harder, and would complicate the field. But I still can't picture malicious zone operators who would voluntarily use ZONEMD. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
> On Jul 29, 2018, at 2:03 PM, Evan Hunt wrote: > > On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote: >> You need to know the hash is valid before you start the download. >> Therefore the hash has to be signed. > > Before you *start* the download? Or before you use what you downloaded? I may be wrong, but I think Ondrej may have been referencing the idea of using BitTorrent where you request the data by its hash value... DW smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
> On Jul 26, 2018, at 7:39 PM, Steve Crocker wrote: > > The passage below puzzles me. Why do you want servers to get the root zone > from less trusted sources? Steve, I wouldn't put it that way. I'd say that the servers shouldn't have to trust the sources, they should have the ability to trust the data itself. > And why does the source matter if the zone entries are DNSSEC-signed? Because many records in the (root) zone are not signed. For example none of this is signed: org.172800 IN NS a0.org.afilias-nst.info. org.172800 IN NS a2.org.afilias-nst.info. org.172800 IN NS b0.org.afilias-nst.org. org.172800 IN NS b2.org.afilias-nst.org. org.172800 IN NS c0.org.afilias-nst.info. org.172800 IN NS d0.org.afilias-nst.org. b0.org.afilias-nst.org. 172800 IN A 199.19.54.1 b0.org.afilias-nst.org. 172800 IN 2001:500:c::1 b2.org.afilias-nst.org. 172800 IN A 199.249.120.1 b2.org.afilias-nst.org. 172800 IN 2001:500:48::1 d0.org.afilias-nst.org. 172800 IN A 199.19.57.1 d0.org.afilias-nst.org. 172800 IN 2001:500:f::1 If you have an RFC7706 recursive name server you could be given a root zone with changed delegations for any TLD. If your recursive name server is validating (which it MUST be per 7706) then probably the worst that would happen is an attack on your privacy. The bad name servers can proxy DNS queries to the real ones and thus log your query traffic. If your name server is not validating then, of course, much worse is possible. DW smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
You can do what BGP implementations have been doing for decades and
just put a count in that allows for some growth. Named and I presume
other servers already has the ability to track records during a zone
transfer (AXFR and IXFR) and abort if the count becomes too large.
The following allows for a ~4x growth.
zone “.” {
type slave;
max-records 10;
…
};
;; XFR size: 22541 records (messages 22541, bytes 2758345)
That said, I agree with Evan, a in zone count is a “nice to have” feature.
Mark
> On 31 Jul 2018, at 3:29 am, Evan Hunt wrote:
>
> On Mon, Jul 30, 2018 at 09:19:14AM +0200, Ondřej Surý wrote:
>> I know some people have 40Gbps at mothers house, but for general
>> usefulness you want to prevent downloading fake (or otherwise invalid)
>> zone before you start downloading it.
>
> While this does seem like a potentially useful feature, I don't think it's
> essential to the problem of verifiable root mirroring. "Nice to have",
> but not a requirement.
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
> On Jul 24, 2018, at 7:32 AM, John Levine wrote: > > In article <87h8kp7sqf@mid.deneb.enyo.de> you write: >> The ZONEMD record should contain a size indicator for the zone, >> something that allows a receiver to stop downloading if it is clear >> that the served zone is too large. Otherwise, the receiver has to >> download the entire zone before it can determine that the hash does >> not match. > > I don't understand why this is a problem that needs solving. Are we > really attacked by broken zone files with large amounts of added junk, > that are so large that reading them through before discarding them is > a practical performance problem? > > I'd think that more likely problems would be that a file was > truncated, or that it was the right size but some entries are > corrupted. I agree with John. ZONEMD is not about securing any particular transport, AXFR or what-have-you. While I wouldn't necessarily be opposed to having an RR count field of some kind if there is good reason to have it, my preference would be to omit it and keep the record simpler. DW smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
> On Jul 28, 2018, at 2:30 AM, Tim Wicinski wrote: > > (these are just my comments alone. So take it as such) Thanks Tim, I don't think these questions are already answered, so thank you for bringing them up. > > The draft states in the Motivation section: > "The motivation and design of this protocol enhancement is tied to the DNS > root zone [InterNIC]." > > Your Design Overview states that this will work for zones that are > "relatively stable and have infrequent updates". I think some descriptive > text about the type of zone this RR type attempts to address should be more > clearly spelled out in your Abstract. Noted. > > For the ZONEMD RR Type, where in the registry do the authors think it should > go? While some of that falls on the Expert Review process, I think the > document authors should capture their rationale in the document. If the > proposed RR Type is greater than 256 (which I think it does), it does not > appear to require a Standards Track document, just Expert Review. Thanks. Is there a proper way to word such a request? Looking at RFC6895 I'm not seeing a real difference in the way that ranges "<=127" and ">=256" are described. > > I ask this since the document is listed as "Standards Track" and the document > is narrowly scoped to focus on the Root Zone. Additionally the document > states: "This specification is OPTIONAL to implement by both publishers and > consumers of zone file data." This appears to be contradictory to me, but > hopefully someone can illuminate me. > > I ask all of this because we have seen the working group start to push back > on similarly scoped Proposed Standards (kskroll-sentinel). > > Though I do find it amusing that you use "The Camel" as the excuse for such a > limited scope use case, even while requesting a Proposed Standard! I can accept that Standards Track is the wrong choice here. Chalk it up to my naïveté. I suppose Experimental would be more appropriate? DW smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Terminology) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Terminology' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-08-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The domain name system (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document will be the successor to RFC 7719, and thus will obsolete RFC 7719. It will also update RFC 2308. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc2308: Negative Caching of DNS Queries (DNS NCACHE) (Proposed Standard - IETF stream) rfc2181: Clarifications to the DNS Specification (Proposed Standard - IETF stream) rfc1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (Proposed Standard - IETF stream) rfc1912: Common DNS Operational and Configuration Errors (Informational - Legacy stream) rfc882: Domain names: Concepts and facilities (Unknown - Legacy stream) rfc6561: Recommendations for the Remediation of Bots in ISP Networks (Informational - IETF stream) rfc6781: DNSSEC Operational Practices, Version 2 (Informational - IETF stream) rfc4592: The Role of Wildcards in the Domain Name System (Proposed Standard - IETF stream) rfc6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) (Proposed Standard - IETF stream) rfc3731: Extensible Provisioning Protocol (EPP) Domain Name Mapping (Proposed Standard - IETF stream) rfc7719: DNS Terminology (Informational - IETF stream) rfc2136: Dynamic Updates in the Domain Name System (DNS UPDATE) (Proposed Standard - IETF stream) rfc5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (Proposed Standard - IETF stream) rfc7344: Automating DNSSEC Delegation Trust Maintenance (Proposed Standard - IETF stream) rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - IETF stream) rfc4034: Resource Records for the DNS Security Extensions (Proposed Standard - IETF stream) rfc8310: Usage Profiles for DNS over TLS and DNS over DTLS (Proposed Standard - IETF stream) rfc4033: DNS Security Introduction and Requirements (Proposed Standard - IETF stream) rfc6841: A Framework for DNSSEC Policies and DNSSEC Practice Statements (Informational - IETF stream) rfc5936: DNS Zone Transfer Protocol (AXFR) (Proposed Standard - IETF stream) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-dnsop-session-signal-12: Discuss 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ -- DISCUSS: -- 1) In addition to the bullet point in the 6.2 that was flagged by Spencer, I would like to discuss the content of section 5.4. (DSO Response Generation). I understand the desire to optimize for the case where the application knows that no data will be sent as reply to a certain message, however, TCP does not have a notion of message boundaries and therefore cannot and should not act based on the reception of a certain message. Indicating to the TCP that an ACK can be set immediately in an specific situation is also problematic as ACK processing is part of the TCP's internal machinery. However, why it is important at all that an TCP-level ACK is send out fast than the delayed ACK timer? The ACK receiver does not expose the information when an ACK is received to the application and the delayed ACK timer only expires if no further data is received/send by the ACK-receiver, therefore this optimization should not have any impact in the application performance. I would just recommend to remove this section and any additional discussion about delayed ACKs. Please note that the problem described in [NagleDA] only occurs for request-response protocols where no further request can be sent before the response is received. This is not the case in this protocol (as pipelining is supported). 2) Further regarding keep-alives: in sec 6.5.2: "For example, a hypothetical keepalive interval value of 100ms would result in a continuous stream of at least ten messages per second, in both directions, to keep the DSO Session alive." This does not seems correct. There should be at max one keep-alives message in flight. Thus the keep-laives timer should only be restarted after the keep-alive reply was received. Also: "And, in this extreme example, a single packet loss and retransmission over a long path could introduce a momentary pause in the stream of messages, long enough to cause the server to overzealously abort the connection." This doesn't really make sense to me: As I said, TCP will retransmit and the keep-alive timer should not be running until the reply is received. If you want to abort the connection based on keep-alives quickly before the TCP connection indicates you a failure, you need to wait at minimum for an interval that is larger than the TCP RTO (with is uaually 3 RTTs) which means you basically need to know the RTT. Also sec 7.1: "If the client does not generate the mandated keepalive traffic, then after twice this interval the server will forcibly abort the connection." Why must the server terminate the connection at all if the client refuses to send keep-alives? Isn't that what the inactivity timer is meant for? Usually only the endpoint that initiates the keep-alive should terminate the connection if no response is received. 3) There is another contraction regarding the inactive timer: Sec 6.2 say "A shorter inactivity timeout with a longer keepalive interval signals to the client that it should not speculatively keep an inactive DSO Session open for very long without reason, but when it does have an active reason to keep a DSO Session open, it doesn't need to be sending an aggressive level of keepalive traffic to maintain that session." which indicates that the client may leave the session open longer than indicated by the inactive timer of the server. However section 7.1.1 say that the client MUST close the connection when the timer is expired. -- COMMENT: -- 1) sec 3: I really find it a bit strange that there is normative language about error handling (as well as in the "same service instance" definition part) in the terminology section. Maybe move those paragraphs somewhere else...? Also the part about "long-lived operations" and messages types provides far more information than just terminology and I would recommend to also move it into an own section or maybe just have it as part of the intro. 2) Maybe call section 5 "Protocol specification" instead of "Protocol details"...? 3) Sec 5.1: "DSO messages MUST be carried in only protocols and in environments where a session may be established according to the
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
Hi Ben, hi all, as you summoned an TSV AD... > Am 27.07.2018 um 17:24 schrieb Benjamin Kaduk : > > I should probably leave this to my (transport-area?) colleagues to discuss > further, but I'm not sure that the interaction of this mechanism with > high-RTT connections is fully covered -- for example, the inactivity > timeout in Section 6.4(.x) could behave poorly when the timeout is set to a > smaller value than the RTT, as the server would potentially end up starting > the "forcibly abort" process (and potentially causing the client to lose > for an hour) because the server's timer starts when it sends the DSO > response that initiates its idea of the session, and would not recieve > graceful shutdown messages from a properly-behaving client in time. My understanding is that they require a minimum time-out of 5 second at the server side, which seems reasonably safe to me. However, maybe this could be further clarified or explained in the doc. Mirja ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
Hi Mirja, On Mon, Jul 30, 2018 at 08:11:52PM +0200, Mirja Kuehlewind (IETF) wrote: > Hi Ben, hi all, > > as you summoned an TSV AD... > > > Am 27.07.2018 um 17:24 schrieb Benjamin Kaduk : > > > > I should probably leave this to my (transport-area?) colleagues to discuss > > further, but I'm not sure that the interaction of this mechanism with > > high-RTT connections is fully covered -- for example, the inactivity > > timeout in Section 6.4(.x) could behave poorly when the timeout is set to a > > smaller value than the RTT, as the server would potentially end up starting > > the "forcibly abort" process (and potentially causing the client to lose > > for an hour) because the server's timer starts when it sends the DSO > > response that initiates its idea of the session, and would not recieve > > graceful shutdown messages from a properly-behaving client in time. > > My understanding is that they require a minimum time-out of 5 second at the > server side, which seems reasonably safe to me. However, maybe this could be > further clarified or explained in the doc. I'm happy to defer to your expertise -- thanks! -Benjamin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
No, not really - you couldn't do NSEC3 with TXT, for example. Or DNAME, or ANY, or lots of things. I'm just using "could I implement this with TXT?" as a proxy for whether it's a major change to the way the DNS works, or just a thing we can move forward on with expert review. Ah. I gather the question is whether the record has semantics beyond just serving it, like DNAME or the proposed BULK, or it's just another record with no special handling. I think we agree this is clearly the latter, since any specialness is outside the DNS query/response protocol. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
On Mon, Jul 30, 2018 at 09:19:14AM +0200, Ondřej Surý wrote: > I know some people have 40Gbps at mothers house, but for general > usefulness you want to prevent downloading fake (or otherwise invalid) > zone before you start downloading it. While this does seem like a potentially useful feature, I don't think it's essential to the problem of verifiable root mirroring. "Nice to have", but not a requirement. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
On Mon, Jul 30, 2018 at 11:03:25AM +1000, Mark Andrews wrote: > Actually it needs to be a type code. How do you hash the TXT RRset and > RRSIG(TXT) RRset when you need to modify both of them after computing the > hash? You need to be able to cleanly exclude the records from the ZONEMD / > XHASH calculations but have a indication that it is present in the zone > (NSEC/NSEC3 bit map). You omit the relevant TXT rrset (_zonehash./TXT, or whatever) when computing the hash for the remainder of the zone. Using a type code is obviously more convenient, but I could implement a zone verification hash without it and so could you. SO, ZONEMD only needs expert review. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
On Sun, Jul 29, 2018 at 09:26:19PM -0400, John Levine wrote: > Well, heck, we could do the whole DNS with TXT records. No, not really - you couldn't do NSEC3 with TXT, for example. Or DNAME, or ANY, or lots of things. I'm just using "could I implement this with TXT?" as a proxy for whether it's a major change to the way the DNS works, or just a thing we can move forward on with expert review. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] We are really lazy in this group
We slept for the last 35 years! "the software originated in the early 1980s at the University of California at Berkeley [...] Not much about the DNS protocol has changed since then." https://www.networkworld.com/article/3293006/internet/ns1s-private-dns-enables-modern-applications-devops-and-more.html ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
On Mon, 30 Jul 2018, Ondřej Surý wrote: I know some people have 40Gbps at mothers house, but for general usefulness you want to prevent downloading fake (or otherwise invalid) zone before you start downloading it. This feels like what we call in the US moving the goalposts. How do you know now that an AXFR isn't going to contain a gigabyte of malware, other than hoping that the other end is trustworthy? Personally, I download linux files by bittorrent without worrying about it, even though I am aware that there are copyright trolls who seed "unauthorized" copies of dirty movies and send out mass infringement threats. How you download and how you verify are separate questions. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Spencer Dawkins' Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
Hi Spencer, hi authors, please see a few comments below. More might be coming as I’m currently reviewing the doc. > Am 27.07.2018 um 06:33 schrieb Spencer Dawkins > : > > Spencer Dawkins has entered the following ballot position for > draft-ietf-dnsop-session-signal-12: Discuss > > 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 IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ > > > > -- > DISCUSS: > -- > > I really like this document, and think it's headed the right direction. Of > course I have four pages of comments, because reasons, but the only part I'm > really confused about is this one ... > > I would have thought that if you end up with a different endpoint because your > anycast address now resolves differently, the new endpoint would have to have > shared a lot of state with the previous endpoint, for this to work: > > When an anycast service is configured on a particular IP address and > port, it must be the case that although there is more than one > physical server responding on that IP address, each such server can > be treated as equivalent. If a change in network topology causes > packets in a particular TCP connection to be sent to an anycast > server instance that does not know about the connection, the normal > keepalive and TCP connection timeout process will allow for recovery. > > What I would have expected to happen, is that the new endpoint sees a packet > arrive that's not on a synchronized TCP connection, and immediately responds > with a RST (reset), rather than the normal keepalive and TCP connection > timeout > process happening. That's also the way I'm reading > https://tools.ietf.org/html/rfc7828#section-3.6. Is that not the way it's > working for anycast these days? I think is what is meant here, is that is a RST is received, the client can reconnect. If the server is not sending a RST, the connection will time out and will be re-established. Especially if only keep-alives are currently send (no application data), a failure can be detected relatively quickly. I do agree that both cases RST and no RST should be mentioned here and the text could be further clarified. > > > -- > COMMENT: > -- > > > Everything else is a comment, so non-blocking, and please do the right thing. > > This is a nit, and your answer could be "no", and that's fine, but in some > places this document uses "DSO keepalive", and in other places, "keepalive" > with no qualifier. It's likely that less confusion would result if you could > consistently call this "DSO keepalive", so that it is clearly NOT a TCP > keepalive. Do the right thing, of course. > > Is the expectation that DSO would also be used in DNS over HTTP? I'm reading > > At the time of publication, DSO is specified only for DNS over TCP > [RFC1035] [RFC7766], and for DNS over TLS over TCP [RFC7858]. Any > use of DSO over some other connection technology needs to be > specified in an appropriate future document. > > and noticing that https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-12 > is currently in IETF Last Call. > > This next one is well within the "Spencer wouldn't have done it this way, but > Spencer's not the working group, or the IETF" range, but > > However, in the typical case a server will not know in advance > whether a client supports DSO, so in general, unless it is known in > advance by other means that a client does support DSO, a server MUST > NOT initiate DSO request messages or DSO unacknowledged messages > until a DSO Session has been mutually established by at least one > successful DSO request/response exchange initiated by the client, as > described below. Similarly, unless it is known in advance by other > means that a server does support DSO, a client MUST NOT initiate DSO > unacknowledged messages until after a DSO Session has been mutually > established. > > seems fragile, especially in environments where clients can come and go, and > servers may be addressed using anycast (so I knew in advance that the four > servers at that anycast address supported DSO, but somebody installed a fifth > server that does not). Is that unlikely to be a problem? > > I'm sure > > A single server may support multiple services, including DNS Updates > [RFC2136], DNS Push Notifications [I-D.ietf-dnssd-push], and
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
On Sun, Jul 29, 2018 at 3:09 PM Steve Crocker wrote: > > Joe, > > As an individuals, you, I, or anyone else, can do whatever we like, of > course. On the other hand, as system designers we presumably look at the > overall system and try to put in place an operational structure that > anticipates and meets the likely needs of the users. > > The present and long-standing system provides the recursive resolvers with > well-oiled and highly effective solutions to (a) finding the root servers and > (b) getting highly reliable and highly responsive answers from them. Nod. > It seems to me reasonable and reasonably easy to sustain these attributes as > we evolve toward downloading the entire root zone instead of individual > pieces of it. Vigorus nod. > And by "evolution" we're necessarily talking about a lengthy period of hybrid > operation. Nod. > There will likely be a growing set of recursive resolvers downloading the > full root zone and but there will certainly be a very large set of recursive > resolvers that continue to operate in the current model. Nod... > Even if there were to be an aggressive push toward hyper local root service, > the existing service would have to remain as is for a long time. And by "a > long time" I'm guessing ten years is not enough, so I suspect it will be > twenty years before one can imagine the current root service reaching > twilight. Nod (I would have said much more than 20 years, but ok). > > The heated concern of several years ago about the potential size of the root > zone is behind us, I hope. The root zone is not going to grow exponentially. > The whole zone will be in the single megabyte range, I think. (Caution: I > haven't looked at the actual size. Apologies if I am off a bit. But the > overall point is still right. Another round or so of gTLDs might double or > even triple the current size of the root zone, but it will not grow by even > one order of magnitude and certainly not by multiple orders of magnitude.) Nod. wkumari$ dig axfr . @b.root-servers.net > root.zone wkumari$ ls -alh root.zone -rw-r--r-- 1 wkumari staff 2.1M Jul 30 10:34 root.zone 2.1MB - close enough. > > Distribution of a megabyte or even a few megabytes to, say, a million > recursive resolvers twice a day is a relatively modest endeavor on today's > Internet. Nod. 2.1MB times 1M resolvers is ~2TB (or the size of a medium capacity SSD drive) > If there are going to be problems, I suspect they won't be related to ad hoc > fetching of the root zone from random untrusted sources. Citation needed :-) Regardless of where I get the root zone (trusted source, untrusted source) I'd like to be able to make sure if it is accurate and complete. For example, I just fetched the root zone via AXFR from b.root-servers.net in MIA, a server which, for various reasons I trust implicitly. However, I'm not really sure I trust the network between it and myself - and if I'm planning on using this zone in a production environment I'd really like to be able to know that someone hasn't monkeyed with it between b.root-servers.net and myself. When I open the zone and it contains: - aaa.172800 IN NS ns1.dns.nic.aaa. aaa.172800 IN NS ns2.dns.nic.aaa. aaa.172800 IN NS ns3.dns.nic.aaa. aaa.172800 IN NS ns4.dns.nic.aaa. aaa.172800 IN NS ns5.dns.nic.aaa. aaa.172800 IN NS ns6.dns.nic.aaa. aaa.86400 IN DS 21707 8 1 6D92DD0D0DB0E392FA9D5F08EA15BBD297B8CBE2 aaa.86400 IN DS 21707 8 2 4F74856F31B73F3BFCDF430985329F55AA655BC9E53C4BF9DC6B14CC E6780600 aaa.86400 IN DS 28192 8 1 563200F63B8B1797B4D88D14BD6A672EA4D0CC0C aaa.86400 IN DS 28192 8 2 DCB5AA6EC2B73D3E8C82D481770151160B38BCF2DBF3B9CD587AAD38 8D3572D7 aaa.86400 IN RRSIG DS 8 1 86400 2018081205 2018073004 41656 . 9pGWZzPrVVFeqif5/PwqlO4BeFcTn2fvE1u5Mv5ADl5xn5vgm1WnWrnB 5Fxuk8TYIWFKhZ19DPk8RaU5Qk/kJpB/7A596x+XJ4IkaaMhlfAWYGYo 9C3cr5yj34FtLKlhU5tE3mSyt4lfyg558hSpwgo6cQPTj78KmkBkzjty X/ZeYTcSZX+zcIK2pNB1bG5yU4IEJbqye4LrKUqVKJ48bJI3pa6tci+b SFkGbqhotRfVdXSuNqZ/njLn+mH/vGIVKlMB5IwLe7Jf7lA1bFlMT4pP BACKPMletFgDMlTaMocqmbRBhRUDHnf93+vSoqxykwB+GLO7A/J3k2FZ NqKDtg== aaa.86400 IN NSECaarp. NS DS RRSIG NSEC aaa.86400 IN RRSIG NSEC 8 1 86400 2018081205 2018073004 41656 . 1MIOeZb204La5r+b71rZxl39WqfVFp4z0kDRh2xd881mW1OICp7zUS1Y qOn/T3WTFQQG+39UVB2uQT+kcwL+rDLN2LGQhTFUzWLTom0oVEzO7rGu zUzbvqMJ0YBtrVqqzxcGYQ0lzGwUgn2qWyFPe6tUXZX3LmJgTT0yHzYT pG0cdEFc/7/7dnXgZIn7LSpOWc8m+Pxz7PSqjQ503cD+UqeJhYRpqTFy YG+UWchXoVZrs0qF6qsqgxdIsGcoeD+0Mh7eondWl4IPNT6UZ1iIxM9q hTNu5y/qyvEW/M20cRGVtY7B9h7RY7d6ASGAbYybeYljG2TBNqYyD9Bh GDg0ow==
Re: [DNSOP] zonemd/xhash versus nothing new
Paul Wouters wrote: > > We are looking at a way to distribute the root zone, presumably to > make the root servers less mission critical and for enhanced > privacy and reduced NXDOMAIN queries. RFC 8198 with qname minimization give you the latter two. > We are depening on DNSSEC for integrity of the data, which just misses > glue/NS verification. I keep thinking it might make sense to sign non-authoritative delegation records, though it's really hard to see how we could get there from here. For instance, there isn't a flags field in RRSIG so you can't explicitly mark an RRset as being non-authoritative. > It seems the way to fix this would be to have well known recursive servers > (8.8.8.8, 1.1.1.1, 4.4.4.4, level3, opendns, etc) also offer the root > zone for AXFR. This just makes the surveillance capitalists part of your mission critical problem area, which isn't obviously an improvement. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher, German Bight: Southerly or southeasterly 4 or 5, occasionally 6 in west Fisher. Slight or moderate. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
John R Levine wrote: > > I'm also thinking the hash wouldn't need to include the RRSIG records, since > those are mechanically derived from the underlying records and the ZSK. If you omit the RRSIGs from the hash, you'll have to verify all the RRSIGs to ensure you aren't serving a bogus zone, and this is more expensive than including the RRSIGs in the hash. Tony. -- f.anthony.n.finchhttp://dotat.at/ Tyne, Dogger: South or southeast veering southwest 4 or 5, occasionally 6 in Dogger. Slight or moderate. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
I know some people have 40Gbps at mothers house, but for general usefulness you want to prevent downloading fake (or otherwise invalid) zone before you start downloading it. Especially, it might be very harmful if the client could be tricked into downloading any data distributed via torrent. You don’t want SWAT unit knocking down your door because your nameserver downloaded Universal Declaration of Human Rights. Ondřej -- Ondřej Surý — ISC > On 29 Jul 2018, at 23:03, Evan Hunt wrote: > >> On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote: >> You need to know the hash is valid before you start the download. >> Therefore the hash has to be signed. > > Before you *start* the download? Or before you use what you downloaded? > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
