Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
On Mar 25, 2015, at 12:19 AM, k...@wide.ad.jp wrote: It is better to describe that the update of the zone can be delayed a little bit as no NOTIFY message is sent to the root-on-loopback. Good point; added. In Appendix A, the root servers listed allow AXFR currently, but I am afraid they don't guarantee it in the future. It may be necessary to confirm it with the operator of each root server listed. The appendix already says: It is crucial to note that none of the above services are guaranteed to be available. It is possible that ICANN or some of the root server operators will turn off the AXFR capability on the servers listed above. Asking any operator to guarantee something in the future doesn't mean they actually will do so, so this warning is more appropriate. In Appendix B, most of the IP addresses of the root DNS servers are anycasted. They are not suitable for the target to pull the zone data in AXFR over TCP. Fully disagree. AXFR of the root zone over TCP over anycast works just fine in all our testing. As Tony Finch points out, it works well in the current Internet. Also it must be noted that these addresses may change over time (while the frequency is not high), it may need to give a warning to periodically check if the addresses are valid. Is the above warning not sufficient? Generating the configuration after priming query? (this is a joke) IMHO, it may necessary to establish an infrastructure to distribute root zone in scalable/reliable manner. Feel free to create such an infrastructure. After it is in place, we can update this document. In the meantime, this document describes a practice that many operators are already using quite successfully. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case
In message alpine.lsu.2.00.1503251055490.23...@hermes-1.csi.cam.ac.uk, Tony Finch writes: John Dickinson j...@sinodun.com wrote: I support this draft. One thing that jumped out to me was there appears to be no mention of NSEC/NSEC3 chain management when adding/removing records. Even if the slave is able to work out what the necessary changes are to the NSEC chain, the master is still going to have to send the new RRSIG records. So I don't think there would be much saving from adding special cases for NSEC and NSEC3. NSEC is a singleton record. Adding a new one indicates a implicit deletion of any other NSEC record at that name. This does not indicate that all NSEC deletes can be removed from the IXFR stream, when constructing a MIXFR stream, only those with a matching addition. Adding a NSEC3 record causes a implicit deletion of the existing NSEC3 with matching parameters. This does not indicate that all NSEC3 deletes can be remove from the IXFR stream, when constructing a MIXFR stream, only those with a matching addition. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Southwest Forties, Cromarty, Forth, Tyne, Dogger: Variable 4 becoming southerly or southeasterly 4 or 5, occasionally 6 later. Slight becoming moderate. Showers. Good, occasionally moderate. ___ 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] draft-ietf-dnsop-root-loopback-01
k...@wide.ad.jp k...@wide.ad.jp wrote: I don't know if such ISPs still exist, but when we started Anycast, it was reported that some ISPs did per-packet load balancing. If they do that they will utterly wreck the performance of unicast TCP, which generally does not cope well with out-of-order packets. The root zone grows over time in almost monotonous manner and longer TCP sessions (especially over narrow bandwidth circuits) could break due to routing change. That's also true for unicast TCP since BGP's typical convergence times are not much longer than TCP connection timeouts. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ North Fisher: Easterly 5 to 7, occasionally gale 8, perhaps severe gale 9 later. Rough or very rough. Rain or snow. Moderate, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
On Mar 25, 2015, at 7:42 AM, Jared Mauch ja...@puck.nether.net wrote: I have a minor nit for consideration: the examples should also include IPv6 loopback ::1 as well. Of what operational value is that? (This is a serious question.) --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
On Mar 25, 2015, at 8:36 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: Feel free to create such an infrastructure. After it is in place, we can update this document. In the meantime, this document describes a practice that many operators are already using quite successfully. --Paul Hoffman I have a minor nit for consideration: the examples should also include IPv6 loopback ::1 as well. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
Jared Mauch wrote: You can read the jabber logs. Let me know if you need help finding them. that's not responsive to my question. (is the definition of an IETF WG's membership still its mailing list not its meeting rooms?) -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
Jared Mauch mailto:ja...@puck.nether.net Wednesday, March 25, 2015 7:56 AM As mentioned in the wg yesterday an informational document with current behaviors may be helpful? as the notes have not been published, those of us not in the room have not had a chance to observe or comment. (is the definition of an IETF WG's membership still its mailing list not its meeting rooms?) -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
On 25 Mar 2015, at 09:52, Paul Vixie p...@redbarn.org wrote: well then it bears further discussion, because to me it's certainly a change. there is no guidance in RFC 1035 as to whether an initiator should treat premature closure by the responder as a signal to try the same server again or move to the next server That sounds like a potentially useful addition to 5966bis - moving on to the next server would seem to me to be the preferred reaction. and, there is no guidance as to whether premature closure is an urgent operational matter deserving notification to the user's console or system logs. IMHO, any client that ever did this is over-reacting and I don’t believe specific guidance is required. A server-initiated close (per 1035) for resource exhaustion reasons might be of note to the server operator, but the client ought to just treat this as a non-event, just like not getting a response to a UDP query. RFC 1035 allows the server to close the connection at any time to reclaim resources. It specifies a generous idle time, but clients cannot assume that this is guaranteed - the server might be restarted, etc. initiators have historically been able to assume that the responder would not close first. In general usage, yes. And that’s still the case, albeit 5966 makes it a bit more likely. that's the operational environment in which RFC 1035 has been interpreted since 1987. if we want the initiator to change its assumptions then we have to say so. the saying of so may or may not constitute a protocol change since we're clarifying the assumptions rather than asking for different behaviour. OK… but since we must also guide the initiator to not leave a tcp session idle, We must? which absolutely is a protocol change, i see no harm is bundling this guidance into a single document which is collectively a revision to the protocol. kind regards Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
On Mar 25, 2015, at 12:19 AM, k...@wide.ad.jp wrote: In Appendix B, most of the IP addresses of the root DNS servers are anycasted. They are not suitable for the target to pull the zone data in AXFR over TCP. I still disagree with the statement that these are not suitable, given that they work fine almost all the time. Proposed addition to alleviate your concern: AXFR transfer over TCP to addresses that are likely to be anycast (as the the ones above are) may have transfer problems different than AXFR over UDP. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 24.3.2015 21:04, Bob Harold wrote: But for the servers and public to know which key to use, there will need to be some id that matches NSEC5 records to the matching NSEC5 key. That requires changing the format of the NSEC5 records, so it cannot be done later. You should never get a zone with NSEC5 records mixed from two different chains. The change of the NSEC5 chain must be atomic. That is required by the draft. What is missing in the draft is, how to determine a correct NSEC5 private key to use to compute the NSEC5 proofs. What comes to my mind is that when the zone is loaded (or the chain is updated), the server could just compute the NSEC5 hash of the zone apex and determine, which key is in use. That could work even without the id. That's simpler, and removes the need for the id. (That's why you are designing this and not me.) Then the process becomes: - add new private key to all authoritative servers. - change NSEC5 key and all NSEC5 records in the master zone - wait for zone to reach all slaves - each time the NSEC5 key record changes, the servers test to see which private key it uses. - remove old private key from all authoritative servers. I agree. I will update the draft to clarify the replacement of the private key during the rollover process. Thank you, Bob. Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
In your previous mail you wrote: = unfortunately this is a change in the protocol the document is not supposed to do here even it both makes sense and follows the real world situation. I disagree that this is a change. RFC 1035 allows the server to close the connection at any time to reclaim resources. It specifies a generous idle time, but clients cannot assume that this is guaranteed - the server might be restarted, etc. = the RFC 1035 problem is it doesn't use the now standard MUST/SHOULD/MAY keywords so it has to be interpreted. In this particular case the cases where the idle time is not granted are clearly exceptions so IMHO the right interpretation is a server SHOULD accept some idle. This is confirmed by Paul Vixie's post and by a private conversation with Mark Andrews: - me - A server should be allowed to use the (idle) timeout it wants, even a zero one. - marka - This will break the SOA + xXFR case. So I am afraid it is both a change and a good topic for a discussion. RFC 1035 also specifies that TCP connections can be closed abruptly, e.g. with a RST. Clients must cope with this. = it doesn't change things (and BTW I believe most programmers even have no idea about how to abort (vs close) a TCP connection :-). A client is buggy if it does not have a mechanism to retry queries that failed because of a broken TCP connection. = I agree but if clients consider a broken TCP connection as an exception, e.g., marking the server as temporary unavailable, we are in trouble with the current proposed text (or mine :-). Thanks francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
Tony Finch mailto:d...@dotat.at Wednesday, March 25, 2015 4:07 AM k...@wide.ad.jp k...@wide.ad.jp wrote: It is better to describe that the update of the zone can be delayed a little bit as no NOTIFY message is sent to the root-on-loopback. The root zone's refresh timer is 30 minutes, and its update interval is about 12 hours. So the delay is very small. nevertheless it's good to describe it. 30 minutes is, and 12 hours certainly is, longer than the usual delay seen by the NOTIFY-speaking servers. In Appendix B, most of the IP addresses of the root DNS servers are anycasted. They are not suitable for the target to pull the zone data in AXFR over TCP. False. Anycast works fine over TCP - see Akamai, Cloudflare, etc. it's not false. most routing changes are path changes not outright withdrawals of the last available path. i would like to see kato's concern added to the document, since anycast tcp is in truth and in fact less stable than unicast tcp, and the more so depending on the width of the anycast footprint. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
Tony Finch wrote: Francis Dupont francis.dup...@fdupont.fr wrote: DNS currently has no connection signaling mechanism. Clients and servers may close a connection at any time. Clients MUST be prepared to retry failed queries on broken connections. = unfortunately this is a change in the protocol the document is not supposed to do here even it both makes sense and follows the real world situation. I disagree that this is a change. well then it bears further discussion, because to me it's certainly a change. there is no guidance in RFC 1035 as to whether an initiator should treat premature closure by the responder as a signal to try the same server again or move to the next server, and, there is no guidance as to whether premature closure is an urgent operational matter deserving notification to the user's console or system logs. RFC 1035 allows the server to close the connection at any time to reclaim resources. It specifies a generous idle time, but clients cannot assume that this is guaranteed - the server might be restarted, etc. initiators have historically been able to assume that the responder would not close first. that's the operational environment in which RFC 1035 has been interpreted since 1987. if we want the initiator to change its assumptions then we have to say so. the saying of so may or may not constitute a protocol change since we're clarifying the assumptions rather than asking for different behaviour. but since we must also guide the initiator to not leave a tcp session idle, which absolutely is a protocol change, i see no harm is bundling this guidance into a single document which is collectively a revision to the protocol. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
I have a minor nit for consideration: the examples should also include IPv6 loopback ::1 as well. I'm with Paul -- every host handles 127/8 loopback addresses and there's no need to use anything else for purely internal communication. Note that this has no effect on whether anything else in your DNS setup supports v6. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
As mentioned in the wg yesterday an informational document with current behaviors may be helpful? Jared Mauch On Mar 25, 2015, at 9:52 AM, Paul Vixie p...@redbarn.org wrote: initiators have historically been able to assume that the responder would not close first. that's the operational environment in which RFC 1035 has been interpreted since 1987. if we want the initiator to change its assumptions then we have to say so. the saying of so may or may not constitute a protocol change since we're clarifying the assumptions rather than asking for different behaviour. but since we must also guide the initiator to not leave a tcp session idle, which absolutely is a protocol change, i see no harm is bundling this guidance into a single document which is collectively a revision to the protocol. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
On Wed, Mar 25, 2015 at 9:57 AM, Paul Vixie p...@redbarn.org wrote: Tony Finch Wednesday, March 25, 2015 7:31 AM k...@wide.ad.jp k...@wide.ad.jp wrote: I don't know if such ISPs still exist, but when we started Anycast, it was reported that some ISPs did per-packet load balancing. If they do that they will utterly wreck the performance of unicast TCP, which generally does not cope well with out-of-order packets. and yet, in a UDP-first UDP-mostly or even UDP-only operating environment, that assumption has been sound. if we're about to make it unsound then we have to say so. I think thats an interesting, and valid point. We've had the luxury of assuming a very high percentage of all DNS except zone tx is UDP, and packet order issues have largely been ignored because they were lost in noise. Now we're exposed to the consequence of flows, packet trains, and its probably true that TCP out of order delivery is going to hit us. I say this, because I have been exposed to precisely this cost from a DC which is doing what Tony describes, and I can see of the order 10x less throughput from DE to AU compared to DE to US, because of this problem in file transfers, because they use odd BGP routing and load management. split path is hard on TCP if the packet order gets tossed. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case
Edward Lewis wrote: I think examining live IXFR flows found in real operations would be very helpful in tuning the implicit delete heuristics that can be employed. If only the primary purpose of IXFR were to reduce traffic. But, the purpose is to reduce CPU load of nameservers serving huge zones. Thus, IXFR over UDP is a good thing to do. However, implicit deletions may increase CPU load if there is nothing to delete, though reduction of TCP traffic may reduce CPU load more. Depending on database structure, wildcard deletions may also increase CPU load. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] another way to minimize ANY responses
Last night the dumb-idea fairy visited me as I was falling asleep, and suggested that another way to reduce the impact of ANY queries would be to pick *one* rrset and return just that. (Probably the numerically smallest rrtype present at the node, plus RRSIGs if any.) This avoids poisoning caches with false NODATA, it works for both DNSSEC and non-DNSSEC zones, meets djb's requirements, makes ANY responses small, and we don't need to argue about what rrtype to use for synthesized responses in non-DNSSEC answers. Still leaks some data (which admittedly undermines the motivation of Olafur's draft) but not as much and what gets leaked would be trivial to acquire by other means anyway. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
Kato san; The current root zone size in the wire format is 539,248 byte. Provided if MTU is 1500, it consists of 367 fragments in UDP. Even if AXFR over UDP is allowed, it may not be practical to assume such number of fragments get delivered without any packet loss especially over a satellite link which is an use case of the draft. Retries could also be fail in this case. Are you talking about jumbogram capable satellite link with link layer fragmentation? Then, the fragmentation mechanism should support SACK like mechanism. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
From: k...@wide.ad.jp Subject: Re: [DNSOP] draft-ietf-dnsop-root-loopback-01 Date: Thu, 26 Mar 2015 04:49:55 +0900 (JST) From: k...@wide.ad.jp Subject: Re: [DNSOP] draft-ietf-dnsop-root-loopback-01 Date: Thu, 26 Mar 2015 04:33:41 +0900 (JST) From: Paul Hoffman paul.hoff...@vpnc.org Subject: Re: [DNSOP] draft-ietf-dnsop-root-loopback-01 Date: Wed, 25 Mar 2015 14:18:59 -0500 On Mar 25, 2015, at 11:06 AM, Evan Hunt e...@isc.org wrote: On Wed, Mar 25, 2015 at 03:53:27PM +, Tony Finch wrote: I think you mean common queries over UDP since AXFR over TCP isn't a thing :-) Or rather AXFR over UDP isn't. TCP is mandatory for *XFR. Where is that requirement made? The only thing I see in RFC 5936 is that AXFR over UDP is not defined. Section 4.3.5 of RFC1034 says: Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests. -- Akira Kato The current root zone size in the wire format is 539,248 byte. Provided if MTU is 1500, it consists of 367 fragments in UDP. Even if AXFR over UDP is allowed, it may not be practical to assume such number of fragments get delivered without any packet loss especially over a satellite link which is an use case of the draft. Retries could also be fail in this case. -- Akira Kato Sorry, I forgot that maximum message size of UDP was 65535. So discussion of AXFR over UDP doesn't make sense as long as we are talking about the root zone. -- Akira Kato ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
I am splitting the thread in separate points. francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on DNS terminology draft
Shumon Huque shu...@gmail.com wrote: Apex -- The SOA and NS RRsets at the origin of a zone. This is also called the zone apex. Why is it only the SOA and NS RRsets? I would suggest defining it in terms of the domain name. Yes. Paul likes to quote existing RFCs, so, the definition in RFC 4033 section 2 is: Zone Apex: Term used to describe the name at the child's side of a zone cut. See also delegation point. RFC 4034 section 4.1.1 says: ... name of the zone apex (the owner name of the zone's SOA RR). Isn't this what the original RFCs defined as the 'top node' (and not specific types of data sets that exist at the top node)? Yes. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: North 6 to gale 8, occasionally severe gale 9 at first near portugal. Rough or very rough becoming moderate or rough. Showers then fair. Moderate or good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case
Matthijs, On Jan 15, 2015, at 5:13 AM, Matthijs Mekking matth...@pletterpet.nlmailto:matth...@pletterpet.nl wrote: IXFR with DNSSEC is suddenly not so small anymore. Do you recognize this? Olafur and I have some ideas on keeping those zone transfers small. Your feedback is appreciated. http://www.ietf.org/internet-drafts/draft-mekking-mixfr-01.txt I support this draft. Steps that can improve the efficiency of DNS are good in my mind (where reduced packet size is to me being efficient). In the Security Considerations section you are asking what you should include in there. I think what you say about using MIXFR over a secure channel and with TSIG is a good recommendation. The question would really be to me - can an attacker do anything different with MIXFR than with IXFR? Could an attacker, for instance, use MIXFR to delete RRSIGs so that portions of a zone were then unsigned? Could multiple MIXFR records be sent at the same time to create confusion? Could a MIXFR be used for a DoS attack? And is any of that different from IXFR? (Or should you then just reference the Security Considerations for IXFR?) I don’t know the answers… but those are the kinds of things I think would be good to discuss in the Security Considerations area. Dan -- Dan York Senior Content Strategist, Internet Society y...@isoc.orgmailto:y...@isoc.org +1-802-735-1624 Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case
John Dickinson j...@sinodun.com wrote: I support this draft. One thing that jumped out to me was there appears to be no mention of NSEC/NSEC3 chain management when adding/removing records. Even if the slave is able to work out what the necessary changes are to the NSEC chain, the master is still going to have to send the new RRSIG records. So I don't think there would be much saving from adding special cases for NSEC and NSEC3. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Southwest Forties, Cromarty, Forth, Tyne, Dogger: Variable 4 becoming southerly or southeasterly 4 or 5, occasionally 6 later. Slight becoming moderate. Showers. Good, occasionally moderate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
k...@wide.ad.jp k...@wide.ad.jp wrote: It is better to describe that the update of the zone can be delayed a little bit as no NOTIFY message is sent to the root-on-loopback. The root zone's refresh timer is 30 minutes, and its update interval is about 12 hours. So the delay is very small. In Appendix B, most of the IP addresses of the root DNS servers are anycasted. They are not suitable for the target to pull the zone data in AXFR over TCP. False. Anycast works fine over TCP - see Akamai, Cloudflare, etc. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Southwest Forties, Cromarty, Forth, Tyne, Dogger: Variable 4 becoming southerly or southeasterly 4 or 5, occasionally 6 later. Slight becoming moderate. Showers. Good, occasionally moderate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
