[dns-operations] anycasting axfr

[Mark Andrews]

In message <20170418134418.3837.qmail at ary.lan>, "John Levine" writes:
> In article <36B261F7-3D5A-4729-9792-718CF7382D22 at rfc1035.com> you write:
> >
> >> On 18 Apr 2017, at 14:00, Tony Finch <dot at dotat.at> wrote:
> >>
> >> You'll have to unpack that for me because I can't see where the
> >> difference is.
> >
> >TCP connections for HTTP tend to be short-lived and/or carry just a few
> >KB of data. AXFRs dont, at least not for big zones slurped across
> >wide-area networks. It usually doesnt matter much if an HTTP connection
> > breaks during a page load either. YMMV.
> >
> >If you need further illimunation, try comparing your browsers TCP
> >behaviour when loading the home page of $favourite-web-site with what dig
> >(say)
> >does for an AXFR of the root or TLD.
>
> You might want to look at slides 18 and 19 of the deck Tony referred to:
>
> https://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf
>
> One of their tests was IPTV downloads where a significant number of
> sessions
> lasted more than 10 minutes. They worked fine, like 99.98% success.
>
> That was 10 years ago but I don't see why the results would be worse now.
>
> R's,
> John
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

And it is not like the root zone actually takes long to tranfer,
nor is it actually that big.  Here are the transfer stats for the
root zone.  This was a trans Pacific zone tranfer.

;; Query time: 7782 msec
;; SERVER: 2001:500:2f::f#53(2001:500:2f::f)
;; WHEN: Wed Apr 19 11:23:16 AEST 2017
;; XFR size: 22524 records (messages 78, bytes 1322902)

Most DNS/TCP responses today are less than 64k as they are for the
few times DNS falls back to TCP.  If you are keeping TCP connections
open longer to handle multiple transactions you need to also support
reconnecting when the TCP connection falls over be that because of
routing changes or the server just shedding TCP load.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org