Re: [DNSOP] the root is not special, everybody please stop obsessing over it
Paul, On Feb 14, 2019, at 1:57 PM, Paul Vixie wrote: > 7706 is wrong headed on a number of levels, but its worst offense is to think > that the root zone is special. Operationally, the root zone actually is special. It is, after all, the starting point of the name space. As far as I can tell, there are 3 ways the root zone is special: 1. How does one obtain name servers for the root zone? How does one obtain name servers for any other zone? 2. Who controls the name servers for the root zone? Who controls the name servers for redbarn.org? 3. What happens if the root zone is unreachable? What happens if redbarn.org is unreachable? 7706 describes one method to improve resiliency, performance, and privacy of root name service, with no modification of the DNS protocol or name servers. It is, of course, possible to do the same thing with any zone, assuming you have enough memory, but few zones generate sufficient interest to do so. Not sure why you’re arguing against it. Could you explain? Regards, -drc signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
sorry, because of my english level, i misused the word "protect". i know the difference between channel security and object security. but in my proposal, the premise is the recursive server should completely trust an Authenticated server. i think this is simialr in DNSSEC, because if an DNSSEC_enabled authotative server(no matter it is Alice or Bob) is evil and modifies DNS records, it will succeed because it has private key and can fake anything. zuop...@cnnic.cn From: Stephane Bortzmeyer Date: 2019-02-14 16:33 To: zuop...@cnnic.cn CC: dnsop; Paul Wouters Subject: Re: [DNSOP] extension of DoH to authoritative servers On Thu, Feb 14, 2019 at 02:36:14PM +0800, zuop...@cnnic.cn wrote a message of 86 lines which said: > i think both DNSSEC and DoH(or DoT) can protect DNS data, "Protect" is like "security", a word so vague, which includes so many different (and sometimes contradictory) services that it is not very useful. Writing "both DNSSEC and DoH(or DoT) can protect DNS data" seems to imply that you did not think enough about the difference between channel security and object security. This is really the weakest point in your argumentation. (Yes, djb always make the same mistake but he is a famous cryptographer so people forget and forgive about his mistakes.) > the fundmental point it to establish the trust chain and transit > trust. No. The entire point of DNSSEC is that you do not need to trust the many servers that are between the validator and the origin. > Regarding the case"secondary name servers mnaged by a different > organisation", the servers can publish several TLSAs to distingush > them. I'm afraid you did not understand. Let me explain with concrete examples. Suppose organisation Alice subcontracts a secondary name server to organisation Bob (a very common use case). 1) What is Bob is evil and modify DNS records? 2) What is Bob is sloppy in security and its servers are cracked and the attacker modify DNS records? DNSSEC protects against both. DoT and DoH does not protect against these issues. > This idea is just a sketch model The problem is that there are many sketch models floating around and few serious proposals (and even less implemented and analyzed proposals). ___ 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] extension of DoH to authoritative servers
On Thu, Feb 14, 2019 at 04:58:38PM +0800, zuop...@cnnic.cn wrote a message of 126 lines which said: > if an DNSSEC_enabled authotative server(no matter it is Alice or > Bob) is evil and modifies DNS records, it will succeed because it > has private key It is completely false. (You seem to think that online signing is the only possibility but this is far from true.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
On Wed, Feb 13, 2019 at 10:51:00PM +0100, Vladimír Čunát wrote a message of 118 lines which said: > Technically you can run DoT on whatever port you like. > Example: with knot-resolver it's easy - you just add @443, either on > side of server and/or on the side of forwarding over TLS. The problem is that you cannot then share this port with HTTPS services (the dkg draft on demultiplexing was abandoned, apparently because it doesn't work). In a world of scarce IPv4 public addresses, this is a serious problem. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
> for instance a DoH or DoT server that intentionally or accidentally returns > false data. DNSSEC can counter that. I dont understand why. If a server intentionally returns false data , it can fake anything because it owns the private key, DNSSEC does not help either. > Indeed. That’s yet another reason why transiting trust is hard. YES. this proposal also needs support from the root. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
On Thu, Feb 14, 2019 at 04:31:35PM +0800, zuop...@cnnic.cn wrote a message of 74 lines which said: > > for instance a DoH or DoT server that intentionally or > > accidentally returns false data. DNSSEC can counter that. > > I dont understand why. > If a server intentionally returns false data , it can fake anything > because it owns the private key, DNSSEC does not help either. So, you seem to not understand DNSSEC very well. I suggest you read RFC 4033 and following. Summary: DNSSEC is designed so that the server does not need the private key. Also, "server" means two VERY different things in the DNS, resolvers and authoritative. DNSSEC protects also against a lying intermediary resolver. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Multiplexing DNS & HTTP over TLS (was: extension of DoH to authoritative servers)
Stephane,
On 14/02/2019 09.05, Stephane Bortzmeyer wrote:
On Wed, Feb 13, 2019 at 10:51:00PM +0100,
Vladimír Čunát wrote
a message of 118 lines which said:
Technically you can run DoT on whatever port you like.
Example: with knot-resolver it's easy - you just add @443, either on
side of server and/or on the side of forwarding over TLS.
The problem is that you cannot then share this port with HTTPS
services (the dkg draft on demultiplexing was abandoned, apparently
because it doesn't work). In a world of scarce IPv4 public addresses,
this is a serious problem.
Interesting. I know that the multi-purpose usage smelled bad but I
didn't know that it didn't work.
Is there a write-up on this?
Thinking about it naively, a demultiplexer really only needs to say "is
there a non-ASCII character in the first 2 or 3 bytes of a TLS session?".
An HTTP message always starts with some ASCII letters, like "GET" or
"HEAD". In contrast, a DNS over TLS client will start with a message
length encoded in 2 bytes. Since in practice queries will be less than
256 bytes and therefore not start out with an ASCII letter (like 'G' or
'H'). Actually this would require a client message of 16705 bytes to
required that *both* the first two bytes are ASCII letters:
>>> (ord('A') << 8) | ord('A')
16705
Since this is only required for the *first* DNS query on a TLS session,
a client could always send a short query as the first one to avoid this
issue. (I'm not sure how this would impact known-text analysis, but
presumably TLS is resistant to this sort of cryptanalysis since HTTP
almost always starts with the same few bytes.)
Even if the two-byte length results in ASCII letters, the client can
sacrifice 1 bit of the message ID and ensure that it always has
non-ASCII values, so the 3rd byte will always be non-ASCII and therefore
not a valid HTTP command. So if it was really necessary to handle the
case of queries of length 16705 or greater for the first query on a
session, a client could always limit its message ID space to 32768
possible values, which should be fine on a stateful connection where
message ID is only used to match out-of-order answers.
I admit the issue of hand-off from a demultiplexer to a DNS server or
HTTP server might be non-trivial, but in principle it should be possible.
Or is the issue to do with TLS itself? I don't know enough about SNI to
know if there may be some reason why HTTP-based TLS could be different
from DNS-based TLS, but I suppose it is possible. 樂
Cheers,
--
Shane
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
On Thu, Feb 14, 2019 at 02:36:14PM +0800, zuop...@cnnic.cn wrote a message of 86 lines which said: > i think both DNSSEC and DoH(or DoT) can protect DNS data, "Protect" is like "security", a word so vague, which includes so many different (and sometimes contradictory) services that it is not very useful. Writing "both DNSSEC and DoH(or DoT) can protect DNS data" seems to imply that you did not think enough about the difference between channel security and object security. This is really the weakest point in your argumentation. (Yes, djb always make the same mistake but he is a famous cryptographer so people forget and forgive about his mistakes.) > the fundmental point it to establish the trust chain and transit > trust. No. The entire point of DNSSEC is that you do not need to trust the many servers that are between the validator and the origin. > Regarding the case"secondary name servers mnaged by a different > organisation", the servers can publish several TLSAs to distingush > them. I'm afraid you did not understand. Let me explain with concrete examples. Suppose organisation Alice subcontracts a secondary name server to organisation Bob (a very common use case). 1) What is Bob is evil and modify DNS records? 2) What is Bob is sloppy in security and its servers are cracked and the attacker modify DNS records? DNSSEC protects against both. DoT and DoH does not protect against these issues. > This idea is just a sketch model The problem is that there are many sketch models floating around and few serious proposals (and even less implemented and analyzed proposals). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
On Thu, Feb 14, 2019 at 04:11:20PM +0800, zuop...@cnnic.cn wrote a message of 102 lines which said: > No. i might did not explain it clearly. It was clear but you repeat the same stuff, without taking into account the remarks (or the existing documents, such as draft-bortzmeyer-dprive-resolver-to-auth). Both Paul Wouters and David Conrad explained that the DNS is more complicated than that (think of forwarders, for instance) and you did not address their remarks. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
> On 14 Feb 2019, at 08:58, zuop...@cnnic.cn wrote: > > the premise is the recursive server should completely trust an Authenticated > server You’ve already made that clear. The problem with that premise is it’s a false one. It represents a naive/unrealistic view of how the DNS is used. Your proposal also needs all the authoritative servers for some zone to be under the same administrative/operational control. That’s also a false premise. And naive/unrealistic. It’s been explained to you that many organisations, TLDs in particular, don’t do that. They arrange service from multiple DNS providers to avoid single points of failure, improve redundancy, have extra capacity, etc, etc. > if an DNSSEC_enabled authotative server(no matter it is Alice or Bob) is evil > and modifies DNS records, it will succeed because it has private key and can > fake anything That premise is wrong too. Only the master server needs access to the private DNSSEC key. That master server isn’t necessarily in the zone's NS RRset and handling queries from resolving servers. Besides, if someone gives their private key to someone else -- in this case another authoritative DNS server -- by definition it isn’t a private key any more. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
On 2/14/19 9:05 AM, Stephane Bortzmeyer wrote: >> Technically you can run DoT on whatever port you like. >> >> Example: with knot-resolver it's easy - you just add @443, either on >> side of server and/or on the side of forwarding over TLS. > The problem is that you cannot then share this port with HTTPS > services (the dkg draft on demultiplexing was abandoned, apparently > because it doesn't work). In a world of scarce IPv4 public addresses, > this is a serious problem. You can still multiplex based on SNI sent by the client. HTTPS clients surely send it commonly. DoT clients perhaps not so often, but that's just an implementation detail (which I was fixing in the past few weeks in knot-resolver, incidentally). I'm not sure how easy SNI-based multiplexing is to configure with nowadays software, but I believe I've heard of some such setup with nginx. And I don't have any idea whether SNI encryption would interfere with that, but I hope not. ESNI will be a key part of DNS privacy, though mainly for the non-DNS traffic. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
Vladimír Čunát writes: > You can still multiplex based on SNI sent by the client. HTTPS clients > surely send it commonly. DoT clients perhaps not so often, but that's > just an implementation detail (which I was fixing in the past few weeks > in knot-resolver, incidentally). My understanding of the reference to BCP195 from https://tools.ietf.org/html/rfc7858#section-3.2 is that SNI support is required for all DoT implementations. > I'm not sure how easy SNI-based multiplexing is to configure with > nowadays software, but I believe I've heard of some such setup with > nginx. And I don't have any idea whether SNI encryption would interfere > with that, but I hope not. ESNI will be a key part of DNS privacy, > though mainly for the non-DNS traffic. It's simple to do with haproxy at least: https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/ ...which incidentally also can be used to support DoT with *any* DNS server as backend. Bjørn ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multiplexing DNS & HTTP over TLS (was: extension of DoH to authoritative servers)
On 14 Feb 2019, at 05:03, Shane Kerr wrote: > On 14/02/2019 09.05, Stephane Bortzmeyer wrote: >> On Wed, Feb 13, 2019 at 10:51:00PM +0100, >> Vladimír Čunát wrote >> a message of 118 lines which said: >>> Technically you can run DoT on whatever port you like. >>> Example: with knot-resolver it's easy - you just add @443, either on >>> side of server and/or on the side of forwarding over TLS. >> The problem is that you cannot then share this port with HTTPS >> services (the dkg draft on demultiplexing was abandoned, apparently >> because it doesn't work). In a world of scarce IPv4 public addresses, >> this is a serious problem. > > Interesting. I know that the multi-purpose usage smelled bad but I didn't > know that it didn't work. > > Is there a write-up on this? > > Thinking about it naively, a demultiplexer really only needs to say "is there > a non-ASCII character in the first 2 or 3 bytes of a TLS session?". I think we can consider explicit payload identification an important feature of successful protocols. Encapsulating layers need to signal key information about the nature of their contents explicitly, or you wind up with the kind of nonsense that we saw in flow-hashing in MPLS where expected network behaviours depended on which transport protocol or address family you happen to be using way up the stack, and ugly hacks abound. Your thought-algorithm above might be ok for discriminating between DoT and HTTPS (although I think anything that depends on a condition like "non-ASCII" is highly suspect :-) but what about other protocols, current and imagined future, that might use TLS as an encapsulating protocol, e.g. to address similar privacy concerns? This doesn't seem like a problem that is particularly theoretical. Running whatever protocol I like on whatever port I like is fine so long as I am informed about the nature of the communication (e.g. I am involved in the decisions at both ends; I configure my ssh client and my ssh server both to use 53/tcp for my own special reasons so the use of that port is understood and doesn't need to be negotiated). In the DNS, one endpoint often has no prior knowledge of even the existence of the other endpoint. Asking one or both sides to make inferences about the nature of a session without explicit signalling does not seem robust. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
Bjørn Mork wrote: > > My understanding of the reference to BCP195 from > https://tools.ietf.org/html/rfc7858#section-3.2 > is that SNI support is required for all DoT implementations. > > It's simple to do with haproxy at least: > https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/ > > ...which incidentally also can be used to support DoT with *any* DNS > server as backend. I'm using nginx as my DoT and DoH front-end proxy (https://github.com/fanf2/doh101/) and it looks like I need to add ssl_preread support to get the SNI https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html I'm only really interested in logging it to see what the clients think they are talking to - they are almost all Androids doing opportunistic DoT. Tony. -- f.anthony.n.finchhttp://dotat.at/ Bailey: Southwest becoming cyclonic, mainly south 5 to 7, occasionally gale 8. High becoming rough or very rough. Occasional rain. Moderate or poor.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multiplexing DNS & HTTP over TLS
On 14.02.19 11:03, Shane Kerr wrote: Stephane, Is there a write-up on this? Thinking about it naively, a demultiplexer really only needs to say "is there a non-ASCII character in the first 2 or 3 bytes of a TLS session?". Hi, please think of HTTP/2, which is a binary protocol (although I don't know what the first bytes are). But I guess ALPN (RFC 7301) would do the trick. Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multiplexing DNS & HTTP over TLS
Klaus, On 14/02/2019 14.00, Klaus Malorny wrote: On 14.02.19 11:03, Shane Kerr wrote: Is there a write-up on this? Thinking about it naively, a demultiplexer really only needs to say "is there a non-ASCII character in the first 2 or 3 bytes of a TLS session?". please think of HTTP/2, which is a binary protocol (although I don't know what the first bytes are). But I guess ALPN (RFC 7301) would do the trick. I think that HTTP/2 preserves the initial handshake of HTTP/1.1. But looking at ALPN, it was designed for exactly this the multiplexing use case. In principle all that would be needed is adding an identifier to the ALPN protocol IDs: https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids It would also address Joe's concerns about other protocols. Maybe creating an ALPN protocol ID for DNS-over-TLS is something for the DPRIVE working group? 樂 Cheers, -- Shane ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp
The call for acceptance for draft-song-atr-large-resp is closed, and it is clear that there is insufficient support to adopt the concept as a DNSOP WG document. There was some concern about the increased number of packages involved in a legitimate exchange (half of them being ICMP messages, introducing other concerns) and that the problem space is too narrow to burden all resolvers. We would like to thank the authors and WG participants who responded to the call for adoption on the mailing list. Best regards, -- Benno DNSOP co-chair On 18/01/2019 18:55, Benno Overeinder wrote: > Dear DNSOP WG, > > We discussed this work (draft -01) in Montreal, and different opinions wrt. > adoption were expressed. In the past months, the authors pushed a draft > version -02 that addressed and resolved some of these comments. > > This starts a Call for Adoption for: > draft-song-atr-large-resp > > The draft is available here: > https://datatracker.ietf.org/doc/draft-song-atr-large-resp/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. The > WG accepts the document or not, but the WG chairs also expect a commitment > from the WG participants who support the document to contribute to the draft, > review, etc. > > The intended status of the draft is Experimental, but we want to ask > developers/vendors if they plan to implement it. > > This call for adoption ends: 1 February 2019 > > Thanks, > > Benno Overeinder > DNSOP co-chair > > > > ___ > 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] Fw: New Version Notification for draft-arnt-yao-dnsop-root-data-caching-00.txt
On Thu, Feb 14, 2019 at 8:59 AM Tony Finch wrote: > Jiankang Yao wrote: > > > >A new draft about root data caching is proposed, which aims to solve > >the similar problem presented in RFC7706 and gives the DNS > >administrator one more option. > > How does this relate to: > > https://tools.ietf.org/html/draft-wkumari-dnsop-hammer and our plan is to still (in our copious free time!) update this to simplify it, and update it to be more of a "this is how implementations have implemented this" -- the document is close to cooked, and we'd dearly love a short bit from implementers describing how they did it... W > > https://tools.ietf.org/html/draft-ietf-dnsop-7706bis > > It looks like this new draft is actually a revision of: > > https://tools.ietf.org/html/draft-yao-dnsop-root-cache > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Trafalgar: Southeast 6 to gale 8. Moderate or rough. Fair. Good. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-arnt-yao-dnsop-root-data-caching-00.txt
> On 14 Feb 2019, at 16:12, Warren Kumari wrote: > > > > On Thu, Feb 14, 2019 at 8:59 AM Tony Finch wrote: > Jiankang Yao wrote: > > > >A new draft about root data caching is proposed, which aims to solve > >the similar problem presented in RFC7706 and gives the DNS > >administrator one more option. > > How does this relate to: > > https://tools.ietf.org/html/draft-wkumari-dnsop-hammer > > ... and our plan is to still (in our copious free time!) update this to > simplify it, and update it to be more of a "this is how implementations have > implemented this" -- the document is close to cooked, and we'd dearly love a > short bit from implementers describing how they did it… > Noted. — Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-arnt-yao-dnsop-root-data-caching-00.txt
Jiankang Yao wrote: > >A new draft about root data caching is proposed, which aims to solve >the similar problem presented in RFC7706 and gives the DNS >administrator one more option. How does this relate to: https://tools.ietf.org/html/draft-wkumari-dnsop-hammer https://tools.ietf.org/html/draft-ietf-dnsop-7706bis It looks like this new draft is actually a revision of: https://tools.ietf.org/html/draft-yao-dnsop-root-cache Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Southeast 6 to gale 8. Moderate or rough. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt
On Mon, Jan 07, 2019 at 12:30:10PM -0800, internet-dra...@ietf.org wrote a message of 44 lines which said: > Title : Extended DNS Errors > Authors : Warren Kumari > Evan Hunt > Roy Arends > Wes Hardaker > David C Lawrence > Filename: draft-ietf-dnsop-extended-error-04.txt Some remarks but before, note I think that it is very important that we have a way to report more detailed error causes. One of the biggest problems of DNSSEC is that there is no easy way for the resolver to report to the application about a DNSSEC problem. So, the work on this draft is essential. Now, the problems: It seems to me that this draft is mostly for resolvers, most planned extended codes are useless for authoritative servers (except may be REFUSED/Lame?). I suggest to make that clear in the introduction: These extended error codes are specially useful for resolvers, to return to stub resolvers or to downstream resolvers. Authoritative servers MAY use them but most error codes would make no sense for them. > Unless a protective transport mechanism (like TSIG [RFC2845] or TLS > [RFC8094]) Why 8094, which does not have even one implementation, instead of 7858? > 4.2.3. SERVFAIL Extended DNS Error Code 3 - Signature Expired > > The resolver attempted to perform DNSSEC validation, but the > signature was expired. I suggest to replace "the signature was expired" by "a signature in the validation chain was expired". Rationale: which signature? What if a DS at the parent is sign with an expired signature? > 4.2.5. SERVFAIL Extended DNS Error Code 5 - DNSKEY missing > > A DS record existed at a parent, but no DNSKEY record could be found > for the child. I suggest to replace "no DNSKEY record could be found for the child" by "no DNSKEY record for this specific key could be found for the child". Rationale : the current text seems to imply this code is only when there is no DNSKEY at all. > 4.4.1. NXDOMAIN Extended DNS Error Code 1 - Blocked > > The resolver attempted to perfom a DNS query but the domain is > blacklisted due to a security policy. The R flag should not be set. The last sentence is touchy. If a stub is configured with two resolvers, and one is fast but known for lying in some cases that you disagree with, you may ask a cookie from the other parent (no, resolver). > 4.4.1. NXDOMAIN Extended DNS Error Code 1 - Blocked > > The resolver attempted to perfom a DNS query but the domain is > blacklisted due to a security policy. I tend to think it would be a good idea to separate the case where the policy was decided by the resolver and the case where the policy came from outside, typically from the local law (see RFC 7725 for a similar case with HTTP). Rationale: in the first case (local policy of the resolver), the user may be interested in talking with the resolver admin if he or she disagrees with the blocking. In the second case, this would be useless. Otherwise, I suggest to add an error code: NOERROR Extended DNS Error Code 3 - Forged answer For policy reasons (legal obligation, or malware filtering, for instance), an answer was forged. The R flag should not be set. Rationale: there is "NXDOMAIN Extended DNS Error Code 1 - Blocked" but policy-aware resolvers (lying resolvers, in plain english) do not always forge NXDOMAIN, they can also forge A or answers. See also the issue just before, about the need to differentiate resolver policy from "upper" policy, law, for instance. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt
On Thu, Feb 07, 2019 at 04:47:01PM +0100, Petr Špaček wrote a message of 129 lines which said: > > 4.1.1. NOERROR Extended DNS Error Code 1 - Unsupported DNSKEY Algorithm > > > >The resolver attempted to perform DNSSEC validation, but a DNSKEY > >RRSET contained only unknown algorithms. The R flag should be set. > > > > 4.1.2. NOERROR Extended DNS Error Code 2 - Unsupported DS Algorithm > > > >The resolver attempted to perform DNSSEC validation, but a DS RRSET > >contained only unknown algorithms. The R flag should be set. > > Why R flag? This is not an error, resolution suceeded, But without the AD flag. > and there is nothing to retry. I propose change both cases to "The R > flag should not be set." In both cases, because another resolver may know other, different algorithms and therefore succeed to validate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt
On 2/14/19 12:51 PM, Stephane Bortzmeyer wrote: > On Mon, Jan 07, 2019 at 12:30:10PM -0800, > internet-dra...@ietf.org wrote > a message of 44 lines which said: > >> Title : Extended DNS Errors >> Authors : Warren Kumari >> Evan Hunt >> Roy Arends >> Wes Hardaker >> David C Lawrence >> Filename: draft-ietf-dnsop-extended-error-04.txt > >> 4.2.5. SERVFAIL Extended DNS Error Code 5 - DNSKEY missing >> >> A DS record existed at a parent, but no DNSKEY record could be found >> for the child. > > I suggest to replace "no DNSKEY record could be found for the child" > by "no DNSKEY record for this specific key could be found for the > child". > > Rationale : the current text seems to imply this code is only when > there is no DNSKEY at all. I disagree. There are going to be cases where DS and DNSKEY are not fully in sync due to key rollovers, prestaging, etc. This is not a fatal error. So long as one DS matches one (supported) DNSKEY, the domain is resolvable, and is not a SERVFAIL. It is only SERVFAIL if *no* DS match useable keys. I would suggest "No supported matching DNSKEY record could be found for the child" -- Michael Sheldon Dev-DNS Services GoDaddy.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-arnt-yao-dnsop-root-data-caching-00.txt
On Thursday 14 February 2019 14:58:58 CET, Tony Finch wrote: How does this relate to: https://tools.ietf.org/html/draft-wkumari-dnsop-hammer https://tools.ietf.org/html/draft-ietf-dnsop-7706bis It originates in various ideas Jiankang and I have chatted about. I didn't like 7706, because I feel that the servers that have long ping times to the nearest root are more likely to have admins who make mistakes. Jiankang and I discussed alternatives when we met a while ago, and a few times since. Once we hit upon this possibility, we didn't discuss draft-wkumari-dnsop-hammer, perhaps because it's expired and we'd forgotten. Mental entropy. Compared to the hammer draft, I should say that this is dead simple, has one fewer acronyms, and that both of those are intentional features. I see your name is in the text. Why did you let it expire? It looks like this new draft is actually a revision of: https://tools.ietf.org/html/draft-yao-dnsop-root-cache Probably correct. IIt was I who did the typing, and I prefer to start by editing something that already has the right XML stuff and at least some references etc. Arnt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multiplexing DNS & HTTP over TLS
In article <9a7b4bc4-018a-9f8c-d3fd-2428356d6...@time-travellers.org> you write: >I think that HTTP/2 preserves the initial handshake of HTTP/1.1. Seems to me you could make it work using SNI, so long as the name you use for the web and DNS servers are different. I realize this makes it more sniffable, but maybe that's less bad than some of the alternatives. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] the root is not special, everybody please stop obsessing over it
7706 is wrong headed on a number of levels, but its worst offense is to think that the root zone is special. we need dns to have leases on its delegation chain including glue and dnssec metadata. everything you might need to use in order to reach a zone authority and trust its results should be kept warm. the owner of the data you've leased must have the ability to reach out and invalidate it in a trusted way. having .CN's delegation data resident because of 7706 doesn't help you reach your own EXAMPLE.CN name servers if the network outage you were concerned about is inside china rather than between china and the rest of the world. NFS gave an example of how to solve this, 25 years ago, with NQLEASE. i am not asking for new computer science, only application of what's already well understood outside the DNS community, as to keeping the hot side hot. unbound has pioneered a bit of this by automatically refetching data that's near its expiration point. we should work from there outward, by standardizing it, prioritizing delegation and dnssec metadata, and exploring ways that the .CN servers could invalidate old NS RRset or DS RRset data (or indeed DNSKEY and RRSIG) if it was willing to do the work of remembering who it had handed the now-invalid data to and what trust markers would be needed to get an RDNS to accept some new form of NOTIFY to purge its cache. _that_ would be complexity worth its cost. 7706 was not. HAMMER is not. indeed nothing which treats the root zone as special is worth pursuing, since many other things besides the root zone are also needed for correct operation during network partition events. the fact that i have to hotwire my RDNS cache with local zone glue in order to reach my own servers when my comcast circuit is down or i can't currently reach the .SU authorities to learn where VIX.SU is, should not only concern, but also embarrass, all of us. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
> On 15 Feb 2019, at 8:57 am, Paul Vixie wrote: > > 7706 is wrong headed on a number of levels, but its worst offense is to think > that the root zone is special. we need dns to have leases on its delegation > chain including glue and dnssec metadata. everything you might need to use in > order to reach a zone authority and trust its results should be kept warm. > the owner of the data you've leased must have the ability to reach out and > invalidate it in a trusted way. > > having .CN's delegation data resident because of 7706 doesn't help you reach > your own EXAMPLE.CN name servers if the network outage you were concerned > about is inside china rather than between china and the rest of the world. > > NFS gave an example of how to solve this, 25 years ago, with NQLEASE. i am > not asking for new computer science, only application of what's already well > understood outside the DNS community, as to keeping the hot side hot. > > unbound has pioneered a bit of this by automatically refetching data that's > near its expiration point. we should work from there outward, by > standardizing it, prioritizing delegation and dnssec metadata, and exploring > ways that the .CN servers could invalidate old NS RRset or DS RRset data (or > indeed DNSKEY and RRSIG) if it was willing to do the work of remembering who > it had handed the now-invalid data to and what trust markers would be needed > to get an RDNS to accept some new form of NOTIFY to purge its cache. > > _that_ would be complexity worth its cost. 7706 was not. HAMMER is not. > indeed nothing which treats the root zone as special is worth pursuing, since > many other things besides the root zone are also needed for correct operation > during network partition events. > > the fact that i have to hotwire my RDNS cache with local zone glue in order > to reach my own servers when my comcast circuit is down or i can't currently > reach the .SU authorities to learn where VIX.SU is, should not only concern, > but also embarrass, all of us. Having the local recursive server having a copy of the local zones was always part of DNS’s deployment model. Having authoritative servers not be recursive servers is not the same as recursive servers not being authoritative for some zones. One thing we missed when adding NOTIFY was adding a NOTIFY-ALSO RRset. In named we work around this by having a also-notify clause in the zone’s configuration clause. DNS RRsets need two TTLs. 1) refresh after in case we need to update. 2) stop believing this result after. With a little bit of EDNS negotiation both can be transmitted in a response. > vixie > > ___ > 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] Fw: New Version Notification for draft-arnt-yao-dnsop-root-data-caching-00.txt
On Thu, Feb 14, 2019 at 12:29 PM Arnt Gulbrandsen
wrote:
> On Thursday 14 February 2019 14:58:58 CET, Tony Finch wrote:
> > How does this relate to:
> >
> > https://tools.ietf.org/html/draft-wkumari-dnsop-hammer
> > https://tools.ietf.org/html/draft-ietf-dnsop-7706bis
>
> It originates in various ideas Jiankang and I have chatted about.
>
> I didn't like 7706, because I feel that the servers that have long ping
> times to the nearest root are more likely to have admins who make
> mistakes.
> Jiankang and I discussed alternatives when we met a while ago, and a few
> times since. Once we hit upon this possibility, we didn't discuss
> draft-wkumari-dnsop-hammer, perhaps because it's expired and we'd
> forgotten. Mental entropy.
>
> Compared to the hammer draft, I should say that this is dead simple, has
> one fewer acronyms, and that both of those are intentional features.
>
> I see your name is in the text. Why did you let it expire?
>
> > It looks like this new draft is actually a revision of:
> >
> > https://tools.ietf.org/html/draft-yao-dnsop-root-cache
>
> Probably correct. IIt was I who did the typing, and I prefer to start by
> editing something that already has the right XML stuff and at least some
> references etc.
>
> Arnt
>
The draft assumes typical TTL is a week, but what I see in the root zone is:
the records for X.root-servers.net are 6 days (518400),
DS, NSEC, RRSIG, and SOA are 1 day (86400), and
A, , DNSKEY, and NS are all 2 days (172800).
I assume the NS records are the most often used?
So I think the draft needs to recalculate the numbers with 2 days as the
typical ttl.
awk '{print $2,$4}' root.zone | sort | uniq -c
2
4159 172800 A
3648 172800
3 172800 DNSKEY
7269 172800 NS
2 172800 RRSIG
13 518400 A
13 518400
13 518400 NS
1 518400 RRSIG
2903 86400 DS
1536 86400 NSEC
2926 86400 RRSIG
2 86400 SOA
1 <<>> 9.11.3-1ubuntu1.3-Ubuntu
1 global +cmd
1 Query 8197
1 SERVER:
1 WHEN: Feb
1 XFR 22488
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt
On Thu, Feb 14, 2019 at 12:34 PM Warren Kumari wrote: > > > On Thu, Feb 14, 2019 at 2:53 PM Stephane Bortzmeyer > wrote: > >> On Mon, Jan 07, 2019 at 12:30:10PM -0800, >> internet-dra...@ietf.org wrote >> a message of 44 lines which said: >> >> > Title : Extended DNS Errors >> > Authors : Warren Kumari >> > Evan Hunt >> > Roy Arends >> > Wes Hardaker >> > David C Lawrence >> > Filename: draft-ietf-dnsop-extended-error-04.txt >> >> Some remarks but before, note I think that it is very important that >> we have a way to report more detailed error causes. One of the biggest >> problems of DNSSEC is that there is no easy way for the resolver to >> report to the application about a DNSSEC problem. So, the work on this >> draft is essential. >> >> > Thank you, I / we certainly think so. > > > >> Now, the problems: >> >> > > 4.2.5. SERVFAIL Extended DNS Error Code 5 - DNSKEY missing >> > >> > A DS record existed at a parent, but no DNSKEY record could be found >> > for the child. >> >> I suggest to replace "no DNSKEY record could be found for the child" >> by "no DNSKEY record for this specific key could be found for the >> child". >> >> > LGTM. > I disagree; I concur with Michael Sheldon (my colleague). I think the semantics that need to be expressed are: "No matching DS/DNSKEY pairs could be found for the child." It doesn't necessarily require the absence of specific DS records in the parent, or DNSKEY records in the child, or the complete absence of e.g. DNSKEYs. It may or may not make any sense to call out other sources of error leading to this condition, e.g. in the EXTRA-TEXT field. (No DNSKEYs; No valid DNSKEYs; No valid DS records; Valid DS with Expired RRSIG; Valid DNSKEY with Expired RRSIG, etc.) And it definitely should only be SERVFAIL iff no matching, valid DS/DNSKEY pairs (i.e. DNSSEC validated DNSKEY, with matching, understood algorithms and non-expired signatures exist). Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt
On Thu, Feb 14, 2019 at 2:53 PM Stephane Bortzmeyer wrote: > On Mon, Jan 07, 2019 at 12:30:10PM -0800, > internet-dra...@ietf.org wrote > a message of 44 lines which said: > > > Title : Extended DNS Errors > > Authors : Warren Kumari > > Evan Hunt > > Roy Arends > > Wes Hardaker > > David C Lawrence > > Filename: draft-ietf-dnsop-extended-error-04.txt > > Some remarks but before, note I think that it is very important that > we have a way to report more detailed error causes. One of the biggest > problems of DNSSEC is that there is no easy way for the resolver to > report to the application about a DNSSEC problem. So, the work on this > draft is essential. > > Thank you, I / we certainly think so. > Now, the problems: > > It seems to me that this draft is mostly for resolvers, most planned > extended codes are useless for authoritative servers (except may be > REFUSED/Lame?). > > I suggest to make that clear in the introduction: > > These extended error codes are specially useful for resolvers, to > return to stub resolvers or to downstream resolvers. Authoritative > servers MAY use them but most error codes would make no sense for > them. > Yup, at the moment the majority of these are resolver errors - I don't think we necessarily expected / thought that through when starting this. I'm guessing that the majority of these will be resolver errors on the future as well, but how about: "The majority of these extended error codes are primarily useful for resolvers, to return to stub resolvers or to downstream resolvers. Authoritative servers may also use this technique to annotate errors (for example, REFUSED), but as of publication there are not as many of these defined" or something? > > > Unless a protective transport mechanism (like TSIG [RFC2845] or TLS > > [RFC8094]) > > Why 8094, which does not have even one implementation, instead of > 7858? > I believe that that was an oversight / error. > > > 4.2.3. SERVFAIL Extended DNS Error Code 3 - Signature Expired > > > > The resolver attempted to perform DNSSEC validation, but the > > signature was expired. > > I suggest to replace "the signature was expired" by "a signature in > the validation chain was expired". > > Rationale: which signature? What if a DS at the parent is sign with an > expired signature? > > LGTM. > > 4.2.5. SERVFAIL Extended DNS Error Code 5 - DNSKEY missing > > > > A DS record existed at a parent, but no DNSKEY record could be found > > for the child. > > I suggest to replace "no DNSKEY record could be found for the child" > by "no DNSKEY record for this specific key could be found for the > child". > > LGTM. > Rationale : the current text seems to imply this code is only when > there is no DNSKEY at all. > > > 4.4.1. NXDOMAIN Extended DNS Error Code 1 - Blocked > > > > The resolver attempted to perfom a DNS query but the domain is > > blacklisted due to a security policy. The R flag should not be set. > > The last sentence is touchy. If a stub is configured with two > resolvers, and one is fast but known for lying in some cases that you > disagree with, you may ask a cookie from the other parent (no, resolver). > Yup. The R flag is entirely, 100% simply a hint - you are perfectly allowed to ignore it, and in this case, you may want to (keep reading!) So, why bother having the flag at all? Primarily it exists so that, if an implementation gets an extended error code which it doesn't understand (e.g 42), it can choose to take the hint, or not. If an implementation *does* understand the code, it can decide it knows better. Now, in this particular case, I think you are right - unless anyone objects, I'm a gonna flip that to "the R flag should be set". > > > 4.4.1. NXDOMAIN Extended DNS Error Code 1 - Blocked > > > > The resolver attempted to perfom a DNS query but the domain is > > blacklisted due to a security policy. > > I tend to think it would be a good idea to separate the case where the > policy was decided by the resolver and the case where the policy came > from outside, typically from the local law (see RFC 7725 for a similar > case with HTTP). > > Rationale: in the first case (local policy of the resolver), the user > may be interested in talking with the resolver admin if he or she > disagrees with the blocking. In the second case, this would be useless. > > Otherwise, I suggest to add an error code: > > NOERROR Extended DNS Error Code 3 - Forged answer > >For policy reasons (legal obligation, or malware filtering, for >instance), an answer was forged. The R flag should not be set. > > Rationale: there is "NXDOMAIN Extended DNS Error Code 1 - Blocked" but > policy-aware resolvers (lying resolvers, in plain english) do not > always forge NXDOMAIN, they can also forge A or answers. > > See also the issue just before, about
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
so, you would like the DNS to be resilient enough to "see" what was topologically reachable and build a connected graph of those assets? I think that has been done, both academically and in a more limited way, commercially, but its not called DNS so as not to upset the DNS mafia. Or do you want something more restrictive than that? /Wm On Thu, Feb 14, 2019 at 4:05 PM Paul Vixie wrote: > > > Evan Hunt wrote on 2019-02-14 15:56: > > On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote: > >> indeed nothing which treats the root zone as special is worth > >> pursuing, since many other things besides the root zone are also > >> needed for correct operation during network partition events. > > > > This point is well taken, but sometimes the root zone is a useful > > test case for innovations that might be more generically useful > > later. It's relatively small, relatively static, *XFR accessible, > > signed but uses NSEC not NSEC3, etc. It's pleasantly free of > > annoyances. > > it's distraction value, where countries lacking root server _operators_ > of their own, feel diminished thereby, and where technology solutions > that affect the root zone in some way, feel unduly relevant... makes it > an _unuseful_ test case. recall that and DS came to every other > zone in the DNS before it was grudgingly admitted into the root zone. > > we have to stop using the root zone as any kind of test case. it's not > special and should be treated unspecially. any technology which focuses > on it should be suspected immediately of "shiny object syndrome." > > > So, zone mirroring fell out of 7706, and I suspect it will > > eventually have broader applications than just local root cache. > > nope. because it did not prototype any partial replication. i'm not > going to mirror COM because i need it to reach FARSIGHTSECURITY.COM. we > needed to focus on partial replication, and avoid any solution that > would only work for small zones that changed infrequently, so as to > avoid wasting years of opportunity on a solution that changed nothing > and led nowhere. > > > I think some of the early work on aggressive negative caching was > > root-specific as well. > > no. in fact, the opposite was true. the first ANC was OTWANC (off the > wire ANC), which had to be specified as part of DLV, which was > instigated in the first place principally because noone knew how many > more years we'd have to wait before a DS RR could be placed into the > root zone. > > > I wouldn't assume an idea is bad just because it's currently focused > > on the root, it might not always be. > > for reasons stated above, there are _no_ counterexamples showing that a > focus on root-specific technology ever did any good, and a plethora of > examples where focus on root-specific technology did some lasting harm. > > therefore, our assumption of any root-specific proposal should be, until > and unless proved otherwise on a case by case basis, that it's "shiny > object syndrome", rather than a legitimate engineering exercise. > > -- > P Vixie > > ___ > 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] the root is not special, everybody please stop obsessing over it
william manning wrote on 2019-02-14 17:35: so, you would like the DNS to be resilient enough to "see" what was topologically reachable and build a connected graph of those assets? no. that's not possible, and not desireable in any case. I think that has been done, both academically and in a more limited way, commercially, but its not called DNS so as not to upset the DNS mafia. Or do you want something more restrictive than that? i want the metadata i need to reach and trust assets on my side of any connectivity loss event, to be kept in warm storage, and made subject to trusted invalidation on an opportunistic basis, at the discretion of the authority operators who own the data i have warm copies of. in practice this means DS/NS and DNSKEY/RRSIG and /A from my static trust anchor(s) down to any data i used recently or frequently (or by some other priority scheme), and i want it to look a bit like the single transaction mode of IXFR plus the single transaction mode of NOTIFY. no topology information as to actual connectivity will be modeled or estimated or needed. what matters is whether i can still reach all internet resources on my side of a break in connectivity (whether local or regional or distant), without needing any information that's otherwise only available on the far side of the connectivity break. thanks for asking; i am happy to clarify. DNS infrastructure should not be centralized, even if its content remains centrally coordinated by ICANN. (block chain people keep telling me that ICANN will be obsolete, but i'm not taking a position on that, only on data resiliency.) -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On 2/14/19 6:51 PM, Paul Vixie wrote: i want the metadata i need to reach and trust assets on my side of any connectivity loss event, to be kept in warm storage, and made subject to trusted invalidation on an opportunistic basis, at the discretion of the authority operators who own the data i have warm copies of. Please explain how "warm storage" relates to priming issues. Does warm mean that it's something you have queried? Or does it also include pertinent (meta)data for interesting things (but not everything) that you've not yet queried? in practice this means DS/NS and DNSKEY/RRSIG and /A from my static trust anchor(s) down to any data i used recently or frequently (or by some other priority scheme), and i want it to look a bit like the single transaction mode of IXFR plus the single transaction mode of NOTIFY. no topology information as to actual connectivity will be modeled or estimated or needed. what matters is whether i can still reach all internet resources on my side of a break in connectivity (whether local or regional or distant), without needing any information that's otherwise only available on the far side of the connectivity break. Does "still reach all internet resources on my side of the break" include things that you've not yet queried for? I'm wondering if a fancier cache of some sort would suffice. Specifically I wonder if BIND (et al) can maintain a FIFO (like) list of QNAMEs, moving the current QNAME to the start of the list, and proactively refreshing the first 10 / 100 / 1000 / pick a number in such a way as to not alter the list position when refreshing. This obviously has a priming problem as a QNAME won't be subject for refresh until /after/ it has been queried the first time. This is why I question your use of the word "warm". Perhaps this can be implemented as part of the existing garbage collection process that remove expired cache entries. If the data to be purged is in the FIFO, then refresh it and cache the results without moving it to the head of the FIFO. The other thing that I might add to this is something to artificially prime the cache by querying for specific names off of a user definable list. How close would something like this be to what you're wanting to see? This would re-use existing mechanism and methodology. It wouldn't see changes in data until after cache expiration. But this is SoP for caches now. thanks for asking; i am happy to clarify. DNS infrastructure should not be centralized, even if its content remains centrally coordinated by ICANN. (block chain people keep telling me that ICANN will be obsolete, but i'm not taking a position on that, only on data resiliency.) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
You are welcome. I think, modulo minor differences in terminology, we are saying pretty much the same thing. pragmatically, DNS infrastructure dependencies can not be maintained and work on data resiliency is where the useful work lies. /Wm On Thu, Feb 14, 2019 at 5:51 PM Paul Vixie wrote: > > > william manning wrote on 2019-02-14 17:35: > > so, you would like the DNS to be resilient enough to "see" what was > > topologically reachable and build a connected graph of those assets? > > no. that's not possible, and not desireable in any case. > > > I think that has been done, both academically and in a more limited way, > > commercially, but its not called DNS so as not to upset the DNS mafia. > > Or do you want something more restrictive than that? > > i want the metadata i need to reach and trust assets on my side of any > connectivity loss event, to be kept in warm storage, and made subject to > trusted invalidation on an opportunistic basis, at the discretion of the > authority operators who own the data i have warm copies of. > > in practice this means DS/NS and DNSKEY/RRSIG and /A from my static > trust anchor(s) down to any data i used recently or frequently (or by > some other priority scheme), and i want it to look a bit like the single > transaction mode of IXFR plus the single transaction mode of NOTIFY. > > no topology information as to actual connectivity will be modeled or > estimated or needed. what matters is whether i can still reach all > internet resources on my side of a break in connectivity (whether local > or regional or distant), without needing any information that's > otherwise only available on the far side of the connectivity break. > > thanks for asking; i am happy to clarify. DNS infrastructure should not > be centralized, even if its content remains centrally coordinated by > ICANN. (block chain people keep telling me that ICANN will be obsolete, > but i'm not taking a position on that, only on data resiliency.) > > -- > P Vixie > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
Grant Taylor wrote on 2019-02-14 18:27: Please explain how "warm storage" relates to priming issues. Does warm mean that it's something you have queried? Or does it also include pertinent (meta)data for interesting things (but not everything) that you've not yet queried? i don't expect anyone to store anything they have not queried, though it's natural for an implementation to permit an operator to statically define other targets as well, much as mark andrews did with "stub" zones starting in 1990 or so in BIND4. Does "still reach all internet resources on my side of the break" include things that you've not yet queried for? no. while there may be some kind of persistent storage of long term popularity information so that things that were ever warm can be kept warm even if not queried since the last reboot cycle, i do not expect any tree-walking exercises. my long term study of RDNS tells me that there is a high correlation between past and future queries. if some query tries to occur during a connectivity break, it might fail, and in that sense it's a DNS problem we've always had, that i'm not solving. ... How close would something like this be to what you're wanting to see? i think leasing behaviour is expensive on a network-wide basis, and should be limited to high-value data, by which i mean metadata needed to reach and trust name servers. so, DS/NS, DNSKEY/RRSIG, and related /A. i do not foresee remembering non-metadata information, no matter how popular, since it's in a content operator's power to put a copy of their DNS infrastructure inside any region that also has a copy of its services. it's only third party metadata, like the delegation and trust chain, that is an unmanageable risk today. also note, i would not propose invalidation on its own merits, because the cost of the data-state and trust-state is too high. however, if we have to maintain that state anyway, for leasing, then invalidation is approximately free, depending on the priorities of the authority server operator. therefore, it becomes a package deal, one stone, two birds. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On Thu, Feb 14, 2019 at 04:05:22PM -0800, Paul Vixie wrote: > nope. because it did not prototype any partial replication. i'm not > going to mirror COM because i need it to reach FARSIGHTSECURITY.COM. I didn't say anybody's going to mirror COM, I said I suspect zone mirroring will find applications other than pre-caching the root. The fact that it isn't a complete solution to the problem space you're interested in at the moment doesn't mean it was useless. That wasn't a major motivation for the work anyway, I don't believe -- my recollection is that it was mainly about reducing garbage traffic, with latency reduction for some resolvers a happy side-effect. Keeping cache data warm and available during network partitions is a largely solved problem; we have prefetch/hammer, we have serve-stale. (Also apparently we have whatever generates all that zombie DNS traffic Geoff discovered back in 2016, but I'd rather avoid perpetuating that mistake, which seems *quite* perpetual enough as it is.) Keeping cache data coherent is less solved: we don't have the trusted invalidation piece you mentioned. I agree that might be a useful line of inquiry. I guess that's the point you were trying to make; I didn't get it immediately because you started off discussing the shortcomings of an RFC that doesn't seem particularly directly related. So let's get specific about the problem and discuss requirements for a solution. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
As we discussed during the interim dprive meeting held last December, we need more empirical studies looking at performance as well as attack vectors. I’m aware of Sinodun’s efforts in this area but are there others that address performance and attack vectors specifically for both DoT and DoH at the authoritative? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
Mark Andrews wrote on 2019-02-14 14:13: ... the fact that i have to hotwire my RDNS cache with local zone glue in order to reach my own servers when my comcast circuit is down or i can't currently reach the .SU authorities to learn where VIX.SU is, should not only concern, but also embarrass, all of us. Having the local recursive server having a copy of the local zones was always part of DNS’s deployment model. Having authoritative servers not be recursive servers is not the same as recursive servers not being authoritative for some zones. i didn't expect you to need the broader example. the narrow example where i can't find my own zones is trivial. it's when i can't find other services whose dns is authoritatively served within my isp or my region, because even though i have connectivity within that isp or that region, there is a political or physical connectivity break between that isp or that region and the rest of the world, for example, the servers for TLD's and 2LD's and 3LD's whose delegators are outside my connectivity. One thing we missed when adding NOTIFY was adding a NOTIFY-ALSO RRset. In named we work around this by having a also-notify clause in the zone’s configuration clause. that won't help. an authority server must have a protocol by which they can, at their own discretion, opportunistically invalidate prior answers, and which can be trusted by the RDNS servers hearing those invalidation messages. DNS RRsets need two TTLs. 1) refresh after in case we need to update. 2) stop believing this result after. With a little bit of EDNS negotiation both can be transmitted in a response. that won't help the case which is more common than connectivity splits, which is where the old data has become harmful (key compromised, server or network offline, emergency renumber or rehoming or rekeying required). let's stop thinking of this as a root problem or a TLD problem. the metadata an RDNS will need to reach and trust servers it can reach, may be on the wrong side of a network partition. that includes the entire NS/DS and DNSKEY/RRSIG chain, plus A/ glue. we need partial zone authority, like a mini-slave, where the RDNS has _subscribed_ to the content it is keeping, and has a potential trust relationship with the owner of that data. we can argue about whether it's like mini-IXFR in which case it can answer authoritatively for the partial data it has leased. but we should not be talking about second TTL's, or root-only solutions like 7706. vixie -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote: > unbound has pioneered a bit of this by automatically refetching data > that's near its expiration point. [...] > _that_ would be complexity worth its cost. 7706 was not. HAMMER is not. I'm confused, what's the difference between HAMMER and the thing you said? (Which BIND also does, incidentally.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote: > indeed nothing which treats the root zone as special is worth pursuing, > since many other things besides the root zone are also needed for > correct operation during network partition events. This point is well taken, but sometimes the root zone is a useful test case for innovations that might be more generically useful later. It's relatively small, relatively static, *XFR accessible, signed but uses NSEC not NSEC3, etc. It's pleasantly free of annoyances. So, zone mirroring fell out of 7706, and I suspect it will eventually have broader applications than just local root cache. I think some of the early work on aggressive negative caching was root-specific as well. I wouldn't assume an idea is bad just because it's currently focused on the root, it might not always be. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
Evan Hunt wrote on 2019-02-14 15:56: On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote: indeed nothing which treats the root zone as special is worth pursuing, since many other things besides the root zone are also needed for correct operation during network partition events. This point is well taken, but sometimes the root zone is a useful test case for innovations that might be more generically useful later. It's relatively small, relatively static, *XFR accessible, signed but uses NSEC not NSEC3, etc. It's pleasantly free of annoyances. it's distraction value, where countries lacking root server _operators_ of their own, feel diminished thereby, and where technology solutions that affect the root zone in some way, feel unduly relevant... makes it an _unuseful_ test case. recall that and DS came to every other zone in the DNS before it was grudgingly admitted into the root zone. we have to stop using the root zone as any kind of test case. it's not special and should be treated unspecially. any technology which focuses on it should be suspected immediately of "shiny object syndrome." So, zone mirroring fell out of 7706, and I suspect it will eventually have broader applications than just local root cache. nope. because it did not prototype any partial replication. i'm not going to mirror COM because i need it to reach FARSIGHTSECURITY.COM. we needed to focus on partial replication, and avoid any solution that would only work for small zones that changed infrequently, so as to avoid wasting years of opportunity on a solution that changed nothing and led nowhere. I think some of the early work on aggressive negative caching was root-specific as well. no. in fact, the opposite was true. the first ANC was OTWANC (off the wire ANC), which had to be specified as part of DLV, which was instigated in the first place principally because noone knew how many more years we'd have to wait before a DS RR could be placed into the root zone. I wouldn't assume an idea is bad just because it's currently focused on the root, it might not always be. for reasons stated above, there are _no_ counterexamples showing that a focus on root-specific technology ever did any good, and a plethora of examples where focus on root-specific technology did some lasting harm. therefore, our assumption of any root-specific proposal should be, until and unless proved otherwise on a case by case basis, that it's "shiny object syndrome", rather than a legitimate engineering exercise. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
