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
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
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
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
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
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
___
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
25 matches
Mail list logo
