RE: dns latency
Bob, I get no real latency doing this, previously I was pinging the GTLD with the high latency from the query and I was not seeing any latency with ping, thus why I emailed the list. Currently doing a dig +trace on comcast.net sees no issues, but per my emails below, there was high latency from the GLTD to comcast’s DNS I even got, dig: couldn't get address for 'dns101.comcast.net': no more at one point. Although now it seems to be back to normal, not sure what to make of it. Thanks for your reply Bob. Paul a ;; Query time: 26 msec b ;; Query time: 172 msec c ;; Query time: 26 msec d ;; Query time: 26 msec e ;; Query time: 76 msec f ;; Query time: 76 msec g ;; Query time: 75 msec h ;; Query time: 8 msec i ;; Query time: 8 msec j ;; Query time: 8 msec k ;; Query time: 38 msec l ;; Query time: 38 msec m ;; Query time: 38 msec From: Bob Harold [mailto:rharo...@umich.edu] Sent: Friday, April 12, 2019 12:52 PM To: Paul A Cc: Mark Andrews ; bind-users@lists.isc.org Subject: Re: dns latency On Fri, Apr 12, 2019 at 12:37 PM Paul A wrote: Mark, per my previous email, this high latency only happens when digging for Comcast. I did not compile bind on this machine, I'm using the latest Bind package that came with CentOS 7, bind-chroot-9.9.4-73.el7_6.x86_64. Looking at the changelog for the RPM it doesn't mention any issue with dig and latency and I assume this has been patched by Redhat at some point. I just wanted to verify that what Im seeing with Comcast is somehow not related to only me and someone else is seeing this issue. The lastest dig I did came back with "dig: couldn't get address for 'dns101.comcast.net': no more" so I doubt it's a dig version issue. Paul ;; Received 239 bytes from 192.5.6.30#53(192.5.6.30) in 32 ms net.172800 IN NS k.gtld-servers.net. net.172800 IN NS b.gtld-servers.net. net.172800 IN NS l.gtld-servers.net. net.172800 IN NS a.gtld-servers.net. net.172800 IN NS m.gtld-servers.net. net.172800 IN NS c.gtld-servers.net. net.172800 IN NS i.gtld-servers.net. net.172800 IN NS e.gtld-servers.net. net.172800 IN NS d.gtld-servers.net. net.172800 IN NS g.gtld-servers.net. net.172800 IN NS h.gtld-servers.net. net.172800 IN NS j.gtld-servers.net. net.172800 IN NS f.gtld-servers.net. net.86400 IN DS 35886 8 2 7862B27F5F516EBE196804 44D4CE5E762981931842C465F00236401D 8BD973EE net.86400 IN RRSIG DS 8 1 86400 2019042505 2019 041204 25266 . Uk5bsrr1dgoBFUYfzSYTi6D+QXow1CZglnE3BUZ7I/I0HjuywiSf2YLx eU1c rjlYOJQdYPxDFQIH5/aItTtrM7wgvTOhfhHPHQuAj2f8ovYIlwCt hguq+9jcNTMAzrUXvi6Tb8oTb36 lprYIfg21yO1d8RO6cx3L0dJMcuez WN2kxNAg+wrx+dWbOexFO7Hs0gzDPpsMx0lEOkJHcfyb/V71An MV+nob 48G/azRzQ2fJfs849OyYmjTXA88bAcxxz3kNCoddOfWuMU+WKV5Lfy7J NkegEfRCzRZYYKiD MwI0zURTg+CdZAYKuxvJQW9ddzSiK5UnYXZVSO1d fPXfYQ== ;; Received 1168 bytes from 199.9.14.201#53(b.root-servers.net) in 88 ms comcast.net.172800 IN NS dns101.comcast.net. comcast.net.172800 IN NS dns102.comcast.net. comcast.net.172800 IN NS dns103.comcast.net. comcast.net.172800 IN NS dns104.comcast.net. comcast.net.172800 IN NS dns105.comcast.net. comcast.net.86400 IN DS 40909 5 2 30C0F50E68DCC9A2F279A9 94C07CF22CED97AADF44C2B1FE38A1B32B A1A34174 comcast.net.86400 IN DS 40909 5 1 DDC19733884EE533B35B4B 57717BEA9B0EF2C4D1 comcast.net.86400 IN RRSIG DS 8 2 86400 20190417054136 2019 0410043136 51638 net. l2Vj2W+qzAziqzcC+Y+t4+6b6ADTwyILCzbySVmj5mj5J9vscR4mYf+f X zNGKen73GecLw+HiwwSzUG8jYkGtvNOMrj9ZbC4v+XWuq0EFcxDEhbJ yTAq2wPMGD6evSUSDLfqYu8h oJH9svqS06KlBjWkKQqx8X+ZIIqmUMVk ivk= dig: couldn't get address for 'dns101.comcast.net': no more -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Friday, April 12, 2019 11:20 AM To: Paul A Cc: bind-users@lists.isc.org Subject: Re: dns latency Before you pay attention to the round trip time you need this fix from BIND 9.9.6 from nearly 5 years ago now (2014-07-31). 3903. [bug] Improve the accuracy of DiG's reported round trip time. [RT 36611] Mark > On 13 Apr 2019, at 12:59 am, Paul A wrote: > > This is not really a Bind issue, but can anyone else confirm latency > when query
Re: dns latency
On Fri, Apr 12, 2019 at 12:37 PM Paul A wrote: > Mark, per my previous email, this high latency only happens when digging > for > Comcast. I did not compile bind on this machine, I'm using the latest Bind > package that came with CentOS 7, bind-chroot-9.9.4-73.el7_6.x86_64. Looking > at the changelog for the RPM it doesn't mention any issue with dig and > latency and I assume this has been patched by Redhat at some point. > > I just wanted to verify that what Im seeing with Comcast is somehow not > related to only me and someone else is seeing this issue. The lastest dig > I > did came back with > "dig: couldn't get address for 'dns101.comcast.net': no more" so I doubt > it's a dig version issue. > > Paul > > > ;; Received 239 bytes from 192.5.6.30#53(192.5.6.30) in 32 ms > > net.172800 IN NS k.gtld-servers.net. > net.172800 IN NS b.gtld-servers.net. > net.172800 IN NS l.gtld-servers.net. > net.172800 IN NS a.gtld-servers.net. > net.172800 IN NS m.gtld-servers.net. > net.172800 IN NS c.gtld-servers.net. > net.172800 IN NS i.gtld-servers.net. > net.172800 IN NS e.gtld-servers.net. > net.172800 IN NS d.gtld-servers.net. > net.172800 IN NS g.gtld-servers.net. > net.172800 IN NS h.gtld-servers.net. > net.172800 IN NS j.gtld-servers.net. > net.172800 IN NS f.gtld-servers.net. > net.86400 IN DS 35886 8 2 > 7862B27F5F516EBE196804 > 44D4CE5E762981931842C465F00236401D 8BD973EE > net.86400 IN RRSIG DS 8 1 86400 2019042505 > 2019 > 041204 25266 . Uk5bsrr1dgoBFUYfzSYTi6D+QXow1CZglnE3BUZ7I/I0HjuywiSf2YLx > eU1c > rjlYOJQdYPxDFQIH5/aItTtrM7wgvTOhfhHPHQuAj2f8ovYIlwCt > hguq+9jcNTMAzrUXvi6Tb8oTb36 > lprYIfg21yO1d8RO6cx3L0dJMcuez > WN2kxNAg+wrx+dWbOexFO7Hs0gzDPpsMx0lEOkJHcfyb/V71An > MV+nob 48G/azRzQ2fJfs849OyYmjTXA88bAcxxz3kNCoddOfWuMU+WKV5Lfy7J > NkegEfRCzRZYYKiD > MwI0zURTg+CdZAYKuxvJQW9ddzSiK5UnYXZVSO1d fPXfYQ== > ;; Received 1168 bytes from 199.9.14.201#53(b.root-servers.net) in 88 ms > > comcast.net.172800 IN NS dns101.comcast.net. > comcast.net.172800 IN NS dns102.comcast.net. > comcast.net.172800 IN NS dns103.comcast.net. > comcast.net.172800 IN NS dns104.comcast.net. > comcast.net.172800 IN NS dns105.comcast.net. > comcast.net.86400 IN DS 40909 5 2 > 30C0F50E68DCC9A2F279A9 > 94C07CF22CED97AADF44C2B1FE38A1B32B A1A34174 > comcast.net.86400 IN DS 40909 5 1 > DDC19733884EE533B35B4B > 57717BEA9B0EF2C4D1 > comcast.net.86400 IN RRSIG DS 8 2 86400 > 20190417054136 > 2019 > 0410043136 51638 net. > l2Vj2W+qzAziqzcC+Y+t4+6b6ADTwyILCzbySVmj5mj5J9vscR4mYf+f X > zNGKen73GecLw+HiwwSzUG8jYkGtvNOMrj9ZbC4v+XWuq0EFcxDEhbJ > yTAq2wPMGD6evSUSDLfqYu8h > oJH9svqS06KlBjWkKQqx8X+ZIIqmUMVk ivk= > dig: couldn't get address for 'dns101.comcast.net': no more > > -Original Message- > From: Mark Andrews [mailto:ma...@isc.org] > Sent: Friday, April 12, 2019 11:20 AM > To: Paul A > Cc: bind-users@lists.isc.org > Subject: Re: dns latency > > Before you pay attention to the round trip time you need this fix from BIND > 9.9.6 from nearly 5 years ago now (2014-07-31). > > 3903. [bug] Improve the accuracy of DiG's reported round trip >time. [RT 36611] > > Mark > > > On 13 Apr 2019, at 12:59 am, Paul A wrote: > > > > This is not really a Bind issue, but can anyone else confirm latency > > when querying Comcast from the root down? I ask because this morning > some > of our customers Could not email @comcast addresses, looked at the mail > server and domain not found. I suspect my cache for Comcast timeout and > when > my DNS server tried doing a new query it timeout on GTLD server to Comcast? > > > > When I query directly to their DNS servers there is no latency, so I > suspect this is a link issue at Comcast affecting DNS? > > > > TIA paul > > > > > > > > ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> @192.5.6.30 comcast.net > > -t a +trace ; (1 server found) ;; global options: +cmd > > . 518400 IN
RE: dns latency
Mark, per my previous email, this high latency only happens when digging for Comcast. I did not compile bind on this machine, I'm using the latest Bind package that came with CentOS 7, bind-chroot-9.9.4-73.el7_6.x86_64. Looking at the changelog for the RPM it doesn't mention any issue with dig and latency and I assume this has been patched by Redhat at some point. I just wanted to verify that what Im seeing with Comcast is somehow not related to only me and someone else is seeing this issue. The lastest dig I did came back with "dig: couldn't get address for 'dns101.comcast.net': no more" so I doubt it's a dig version issue. Paul ;; Received 239 bytes from 192.5.6.30#53(192.5.6.30) in 32 ms net.172800 IN NS k.gtld-servers.net. net.172800 IN NS b.gtld-servers.net. net.172800 IN NS l.gtld-servers.net. net.172800 IN NS a.gtld-servers.net. net.172800 IN NS m.gtld-servers.net. net.172800 IN NS c.gtld-servers.net. net.172800 IN NS i.gtld-servers.net. net.172800 IN NS e.gtld-servers.net. net.172800 IN NS d.gtld-servers.net. net.172800 IN NS g.gtld-servers.net. net.172800 IN NS h.gtld-servers.net. net.172800 IN NS j.gtld-servers.net. net.172800 IN NS f.gtld-servers.net. net.86400 IN DS 35886 8 2 7862B27F5F516EBE196804 44D4CE5E762981931842C465F00236401D 8BD973EE net.86400 IN RRSIG DS 8 1 86400 2019042505 2019 041204 25266 . Uk5bsrr1dgoBFUYfzSYTi6D+QXow1CZglnE3BUZ7I/I0HjuywiSf2YLx eU1c rjlYOJQdYPxDFQIH5/aItTtrM7wgvTOhfhHPHQuAj2f8ovYIlwCt hguq+9jcNTMAzrUXvi6Tb8oTb36 lprYIfg21yO1d8RO6cx3L0dJMcuez WN2kxNAg+wrx+dWbOexFO7Hs0gzDPpsMx0lEOkJHcfyb/V71An MV+nob 48G/azRzQ2fJfs849OyYmjTXA88bAcxxz3kNCoddOfWuMU+WKV5Lfy7J NkegEfRCzRZYYKiD MwI0zURTg+CdZAYKuxvJQW9ddzSiK5UnYXZVSO1d fPXfYQ== ;; Received 1168 bytes from 199.9.14.201#53(b.root-servers.net) in 88 ms comcast.net.172800 IN NS dns101.comcast.net. comcast.net.172800 IN NS dns102.comcast.net. comcast.net.172800 IN NS dns103.comcast.net. comcast.net.172800 IN NS dns104.comcast.net. comcast.net.172800 IN NS dns105.comcast.net. comcast.net.86400 IN DS 40909 5 2 30C0F50E68DCC9A2F279A9 94C07CF22CED97AADF44C2B1FE38A1B32B A1A34174 comcast.net.86400 IN DS 40909 5 1 DDC19733884EE533B35B4B 57717BEA9B0EF2C4D1 comcast.net.86400 IN RRSIG DS 8 2 86400 20190417054136 2019 0410043136 51638 net. l2Vj2W+qzAziqzcC+Y+t4+6b6ADTwyILCzbySVmj5mj5J9vscR4mYf+f X zNGKen73GecLw+HiwwSzUG8jYkGtvNOMrj9ZbC4v+XWuq0EFcxDEhbJ yTAq2wPMGD6evSUSDLfqYu8h oJH9svqS06KlBjWkKQqx8X+ZIIqmUMVk ivk= dig: couldn't get address for 'dns101.comcast.net': no more -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Friday, April 12, 2019 11:20 AM To: Paul A Cc: bind-users@lists.isc.org Subject: Re: dns latency Before you pay attention to the round trip time you need this fix from BIND 9.9.6 from nearly 5 years ago now (2014-07-31). 3903. [bug] Improve the accuracy of DiG's reported round trip time. [RT 36611] Mark > On 13 Apr 2019, at 12:59 am, Paul A wrote: > > This is not really a Bind issue, but can anyone else confirm latency > when querying Comcast from the root down? I ask because this morning some of our customers Could not email @comcast addresses, looked at the mail server and domain not found. I suspect my cache for Comcast timeout and when my DNS server tried doing a new query it timeout on GTLD server to Comcast? > > When I query directly to their DNS servers there is no latency, so I suspect this is a link issue at Comcast affecting DNS? > > TIA paul > > > > ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> @192.5.6.30 comcast.net > -t a +trace ; (1 server found) ;; global options: +cmd > . 518400 IN NS i.root-servers.net. > . 518400 IN NS j.root-servers.net. > . 518400 IN NS k.root-servers.net. > . 518400 IN NS l.root-servers.net. > . 518400 IN NS m.root-servers.net. > . 518400 IN NS a.root-servers.net. > . 518400 IN NS b.root-servers.net. > . 518400 IN NS c.root-serv
Re: dns latency
Before you pay attention to the round trip time you need this fix from BIND 9.9.6 from nearly 5 years ago now (2014-07-31). 3903. [bug] Improve the accuracy of DiG's reported round trip time. [RT 36611] Mark > On 13 Apr 2019, at 12:59 am, Paul A wrote: > > This is not really a Bind issue, but can anyone else confirm latency when > querying Comcast from the root down? I ask because this morning some of our > customers > Could not email @comcast addresses, looked at the mail server and domain not > found. I suspect my cache for Comcast timeout and when my DNS server tried > doing a new query it timeout on GTLD server to Comcast? > > When I query directly to their DNS servers there is no latency, so I suspect > this is a link issue at Comcast affecting DNS? > > TIA paul > > > > ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> @192.5.6.30 comcast.net -t a > +trace > ; (1 server found) > ;; global options: +cmd > . 518400 IN NS i.root-servers.net. > . 518400 IN NS j.root-servers.net. > . 518400 IN NS k.root-servers.net. > . 518400 IN NS l.root-servers.net. > . 518400 IN NS m.root-servers.net. > . 518400 IN NS a.root-servers.net. > . 518400 IN NS b.root-servers.net. > . 518400 IN NS c.root-servers.net. > . 518400 IN NS d.root-servers.net. > . 518400 IN NS e.root-servers.net. > . 518400 IN NS f.root-servers.net. > . 518400 IN NS g.root-servers.net. > . 518400 IN NS h.root-servers.net. > ;; Received 239 bytes from 192.5.6.30#53(192.5.6.30) in 32 ms > > net.172800 IN NS a.gtld-servers.net. > net.172800 IN NS b.gtld-servers.net. > net.172800 IN NS c.gtld-servers.net. > net.172800 IN NS d.gtld-servers.net. > net.172800 IN NS e.gtld-servers.net. > net.172800 IN NS f.gtld-servers.net. > net.172800 IN NS g.gtld-servers.net. > net.172800 IN NS h.gtld-servers.net. > net.172800 IN NS i.gtld-servers.net. > net.172800 IN NS j.gtld-servers.net. > net.172800 IN NS k.gtld-servers.net. > net.172800 IN NS l.gtld-servers.net. > net.172800 IN NS m.gtld-servers.net. > net.86400 IN DS 35886 8 2 > 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE > net.86400 IN RRSIG DS 8 1 86400 2019042505 > 2019041204 25266 . > Uk5bsrr1dgoBFUYfzSYTi6D+QXow1CZglnE3BUZ7I/I0HjuywiSf2YLx > eU1crjlYOJQdYPxDFQIH5/aItTtrM7wgvTOhfhHPHQuAj2f8ovYIlwCt > hguq+9jcNTMAzrUXvi6Tb8oTb36lprYIfg21yO1d8RO6cx3L0dJMcuez > WN2kxNAg+wrx+dWbOexFO7Hs0gzDPpsMx0lEOkJHcfyb/V71AnMV+nob > 48G/azRzQ2fJfs849OyYmjTXA88bAcxxz3kNCoddOfWuMU+WKV5Lfy7J > NkegEfRCzRZYYKiDMwI0zURTg+CdZAYKuxvJQW9ddzSiK5UnYXZVSO1d fPXfYQ== > ;; Received 1168 bytes from 198.97.190.53#53(h.root-servers.net) in 19 ms > > comcast.net.172800 IN NS dns101.comcast.net. > comcast.net.172800 IN NS dns102.comcast.net. > comcast.net.172800 IN NS dns103.comcast.net. > comcast.net.172800 IN NS dns104.comcast.net. > comcast.net.172800 IN NS dns105.comcast.net. > comcast.net.86400 IN DS 40909 5 2 > 30C0F50E68DCC9A2F279A994C07CF22CED97AADF44C2B1FE38A1B32B A1A34174 > comcast.net.86400 IN DS 40909 5 1 > DDC19733884EE533B35B4B57717BEA9B0EF2C4D1 > comcast.net.86400 IN RRSIG DS 8 2 86400 20190417054136 > 20190410043136 51638 net. > l2Vj2W+qzAziqzcC+Y+t4+6b6ADTwyILCzbySVmj5mj5J9vscR4mYf+f > XzNGKen73GecLw+HiwwSzUG8jYkGtvNOMrj9ZbC4v+XWuq0EFcxDEhbJ > yTAq2wPMGD6evSUSDLfqYu8hoJH9svqS06KlBjWkKQqx8X+ZIIqmUMVk ivk= > ;; Received 612 bytes from 192.42.93.30#53(g.gtld-servers.net) in 25090 ms > > comcast.net.30 IN A 69.252.80.75 > comcast.net.30 IN RRSIG A 5 2 30 20190418174157 > 20190411143657 26550 comcast.net. > YegwZlzjBoJ+b9nWTHwRZQbce619UcOVdo6FUPG056Sod4MEchv/GCHu > 7BpREAUm0CBoE4qbipTiS47wIk7QJYzz10B78wRgMGNwMTUXQ571YRyq > P0I3I0Dzag28j607walJOZms3lAXDzSnyvv9wocaH2MJ7Z3j68Qf5pKh YpM= > ;; Received 227 bytes from 69.252.250.103#53(dns101.comcast.net) in 14 ms > > ___ > Pleas
dns latency
This is not really a Bind issue, but can anyone else confirm latency when querying Comcast from the root down? I ask because this morning some of our customers Could not email @comcast addresses, looked at the mail server and domain not found. I suspect my cache for Comcast timeout and when my DNS server tried doing a new query it timeout on GTLD server to Comcast? When I query directly to their DNS servers there is no latency, so I suspect this is a link issue at Comcast affecting DNS? TIA paul ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> @192.5.6.30 comcast.net -t a +trace ; (1 server found) ;; global options: +cmd . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS h.root-servers.net. ;; Received 239 bytes from 192.5.6.30#53(192.5.6.30) in 32 ms net.172800 IN NS a.gtld-servers.net. net.172800 IN NS b.gtld-servers.net. net.172800 IN NS c.gtld-servers.net. net.172800 IN NS d.gtld-servers.net. net.172800 IN NS e.gtld-servers.net. net.172800 IN NS f.gtld-servers.net. net.172800 IN NS g.gtld-servers.net. net.172800 IN NS h.gtld-servers.net. net.172800 IN NS i.gtld-servers.net. net.172800 IN NS j.gtld-servers.net. net.172800 IN NS k.gtld-servers.net. net.172800 IN NS l.gtld-servers.net. net.172800 IN NS m.gtld-servers.net. net.86400 IN DS 35886 8 2 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE net.86400 IN RRSIG DS 8 1 86400 2019042505 2019041204 25266 . Uk5bsrr1dgoBFUYfzSYTi6D+QXow1CZglnE3BUZ7I/I0HjuywiSf2YLx eU1crjlYOJQdYPxDFQIH5/aItTtrM7wgvTOhfhHPHQuAj2f8ovYIlwCt hguq+9jcNTMAzrUXvi6Tb8oTb36lprYIfg21yO1d8RO6cx3L0dJMcuez WN2kxNAg+wrx+dWbOexFO7Hs0gzDPpsMx0lEOkJHcfyb/V71AnMV+nob 48G/azRzQ2fJfs849OyYmjTXA88bAcxxz3kNCoddOfWuMU+WKV5Lfy7J NkegEfRCzRZYYKiDMwI0zURTg+CdZAYKuxvJQW9ddzSiK5UnYXZVSO1d fPXfYQ== ;; Received 1168 bytes from 198.97.190.53#53(h.root-servers.net) in 19 ms comcast.net.172800 IN NS dns101.comcast.net. comcast.net.172800 IN NS dns102.comcast.net. comcast.net.172800 IN NS dns103.comcast.net. comcast.net.172800 IN NS dns104.comcast.net. comcast.net.172800 IN NS dns105.comcast.net. comcast.net.86400 IN DS 40909 5 2 30C0F50E68DCC9A2F279A994C07CF22CED97AADF44C2B1FE38A1B32B A1A34174 comcast.net.86400 IN DS 40909 5 1 DDC19733884EE533B35B4B57717BEA9B0EF2C4D1 comcast.net.86400 IN RRSIG DS 8 2 86400 20190417054136 20190410043136 51638 net. l2Vj2W+qzAziqzcC+Y+t4+6b6ADTwyILCzbySVmj5mj5J9vscR4mYf+f XzNGKen73GecLw+HiwwSzUG8jYkGtvNOMrj9ZbC4v+XWuq0EFcxDEhbJ yTAq2wPMGD6evSUSDLfqYu8hoJH9svqS06KlBjWkKQqx8X+ZIIqmUMVk ivk= ;; Received 612 bytes from 192.42.93.30#53(g.gtld-servers.net) in 25090 ms comcast.net.30 IN A 69.252.80.75 comcast.net.30 IN RRSIG A 5 2 30 20190418174157 20190411143657 26550 comcast.net. YegwZlzjBoJ+b9nWTHwRZQbce619UcOVdo6FUPG056Sod4MEchv/GCHu 7BpREAUm0CBoE4qbipTiS47wIk7QJYzz10B78wRgMGNwMTUXQ571YRyq P0I3I0Dzag28j607walJOZms3lAXDzSnyvv9wocaH2MJ7Z3j68Qf5pKh YpM= ;; Received 227 bytes from 69.252.250.103#53(dns101.comcast.net) in 14 ms ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS latency!!!
On Aug 16, 2010, at 11:55 , Yohann Lepage wrote: > 2010/8/16 Shiva Raman >> Which is the best method to measure dns latency ? Is there any scripts / >> programs >> available to measure the dns latency directly? I would like to remind people of the most obvious one: dig sh-4.1$ dig localhost ; <<>> DiG 9.7.1-P2 <<>> localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23311 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;localhost. IN A ;; ANSWER SECTION: localhost. 86400 IN A 127.0.0.1 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Aug 18 11:30:12 2010 ;; MSG SIZE rcvd: 43 See the Query time column. Stefan ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS latency!!!
2010/8/16 Shiva Raman > Hi All Hi, > Which is the best method to measure dns latency ? Is there any scripts / > programs > available to measure the dns latency directly? - queryperf : /bind-9.7.1-P2/contrib/queryperf/ - dnsperf : http://www.nominum.com/services/measurement_tools.php -DNS benchmark http://www.grc.com/dns/benchmark.htm -And if you have money : http://www.spirent.com/Solutions-Directory/Avalanche.aspx Regards, Yohann > > Regards > > Shiva Raman ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS latency!!!
In article , Shiva Raman wrote: > Hi All > > Which is the best method to measure dns latency ? Is there any scripts / > programs > available to measure the dns latency directly? Google Namebench. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNS latency!!!
Hi All Which is the best method to measure dns latency ? Is there any scripts / programs available to measure the dns latency directly? Regards Shiva Raman ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
