In <[EMAIL PROTECTED]> Brad Knowles <[EMAIL PROTECTED]> writes:

> At 1:34 PM -0500 2005-07-28, wayne wrote:
>
>>  The truncation isn't *too* bad since it is just the A records for the
>>  name servers that are getting tossed.  That will cause uneven load on
>>  the various pool name servers, but not on the pool NTP servers
>>  themselves.
>
>       Any time there's truncation, the resolvers have to retry with
>       TCP.

Ok, I guess I used the term "truncation" when I shouldn't have, it
wasn't what I meant and I should know better.

Are/were the packets really being truncated, with the TC bit being set
and all?   Or, were just some of the additional records being not
being included?  (The latter is what I meant, but not what I said.)


This is what I'm currently getting:

([EMAIL PROTECTED]) $ dig @202.49.59.6 pool.ntp.org

; <<>> DiG 9.3.1 <<>> @202.49.59.6 pool.ntp.org
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25001
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 15, AUTHORITY: 5, ADDITIONAL: 4

;; QUESTION SECTION:
;pool.ntp.org.                  IN      A

;; ANSWER SECTION:
pool.ntp.org.           120     IN      A       216.221.85.101
pool.ntp.org.           120     IN      A       217.125.14.244
pool.ntp.org.           120     IN      A       64.109.43.141
pool.ntp.org.           120     IN      A       81.56.228.174
pool.ntp.org.           120     IN      A       82.76.121.165
pool.ntp.org.           120     IN      A       83.245.15.238
pool.ntp.org.           120     IN      A       130.60.75.75
pool.ntp.org.           120     IN      A       146.48.83.182
pool.ntp.org.           120     IN      A       198.144.194.12
pool.ntp.org.           120     IN      A       200.23.51.205
pool.ntp.org.           120     IN      A       202.150.105.150
pool.ntp.org.           120     IN      A       202.173.190.158
pool.ntp.org.           120     IN      A       209.204.159.18
pool.ntp.org.           120     IN      A       213.10.208.72
pool.ntp.org.           120     IN      A       213.84.14.16

;; AUTHORITY SECTION:
pool.ntp.org.           86400   IN      NS      aventura.bhms-groep.nl.
pool.ntp.org.           86400   IN      NS      ns1.us.bitnames.com.
pool.ntp.org.           86400   IN      NS      ns1.mailworx.net.
pool.ntp.org.           86400   IN      NS      usenet.net.nz.
pool.ntp.org.           86400   IN      NS      zbasel.fortytwo.ch.

;; ADDITIONAL SECTION:
ns1.mailworx.net.       7395    IN      A       69.1.200.68
usenet.net.nz.          5400    IN      A       202.49.59.6
zbasel.fortytwo.ch.     49267   IN      A       193.138.215.60
aventura.bhms-groep.nl. 13428   IN      A       217.114.97.98

;; Query time: 228 msec
;; SERVER: 202.49.59.6#53(202.49.59.6)
;; WHEN: Fri Jul 29 11:58:21 2005
;; MSG SIZE  rcvd: 492



No, you can see that the "received messsage size" is 492 bytes, which
is right up at the edge.  In the additional section, only 4 of the 5
name servers have A records provided.  It is my understanding that the
additional records are optional and it is OK for name servers to not
put them in when they don't fit.

I don't see any mention of the TC bit being set, nor a warning about
falling back to TCP.


Granted, this is after Ask reduced the number of name servers.


I really suspect that we don't need more than 3 name servers, as long
as they are both geographically and network topologically diverse,
they are well run, and they have a reasonable amount of bandwidth.


-wayne
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers

Reply via email to