Re: [dnsop] Re: Root Anycast (fwd)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 30 Sep 2004, John Brown CT wrote:

> Couple of points here.
> 
> 1. Typical DNS queries are via UDP, not TCP.
>     Thus the noise Dean is making here about things breaking
>     because of TCP issues, is well  noise.

Noise about TCP, yes.

>     Keep in mind that DNS queries are UDP.  The query and the response.
>     so a typical query is 2 packets, the ask and the answer.
>
>     Having DNS be based on TCP would NOT scale very well.  

We know. As you point out, TCP is still used.  

> Think about
>     it.  Before I could even make a query I would have to deal with
>     at least 3 packets for the TCP connection setup.  Then I'd send my
>     query, which would also have an TCP ACK sent as well, oh then there
>     is the answer to the query, with yet another TCP ACK.  So a single
>     DNS query would (at a min) take 7 packets, more likely 8 to 10,
>     thats 400 to 500 percent more traffic than via UDP.

We know. But people still propose things that will take big packets or 
DNSSEC, etc.

>     DNS uses TCP in special cases. Some of them, but not all of them
>     are.  1. Packet size, 2. AXFR, 3. I think TSIG / DNS SeC stuff
> 
>     Now before Dean jumps on the See, AXFR is broke, lets understand that
>     AXFR doesn't happen for anycasted root servers on their PUBLIC facing
>     IP address.  AXFR is typically going to happen on a globally unique
>     IP assigned to each specific Anycast'd host.  Thus TCP works just
>     fine.

Yes, I'll accept that roots can be updated via means other than AXFR and
updated via other than anycasted IP addresses.

> 
> 2. This "single router requirement" is an interesting comment.  I've not
>     seen this in any RFC or BCP.  Is there one ??  I'd hope not.

A BCP/RFC for what?  You mean anycast? I don't know if it is in the RFC
describing anycast.  However, that is obviously a requirement, as pointed
out previously by others.

>     Having muliple routers in a mesh format is good.  That means if one
>     router fails the other can take the traffic.

No doubt.

>     Keep in mind that from a packet path forwarding decision process,
>     these routers are speaking other protocols as well.  There is dynamic
>     information being shared between these closely coupled routers that
>     lets them do the right thing.

Really?  And what protocols are those?

		--Dean


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]