RE: dns latency

2019-04-12 Thread Paul A
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 querying Comcast from the root down? I ask because this morning  some

Re: dns latency

2019-04-12 Thread Bob Harold
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  NS  i.root-servers.net.
> > .   

RE: dns latency

2019-04-12 Thread Paul A
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-servers.net.
> .   518400  IN  

Re: dns latency

2019-04-12 Thread Mark Andrews
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
>  
> ___
> 

dns latency

2019-04-12 Thread Paul A
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!!!

2010-08-18 Thread Stefan Schmidt

On Aug 16, 2010, at 11:55 , Yohann Lepage wrote:

 2010/8/16 Shiva Raman raman.shi...@gmail.com
   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-08-16 Thread Yohann Lepage
2010/8/16 Shiva Raman raman.shi...@gmail.com
 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

DNS latency!!!

2010-08-15 Thread Shiva Raman
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

Re: DNS latency!!!

2010-08-15 Thread Barry Margolin
In article mailman.342.1281936543.15649.bind-us...@lists.isc.org,
 Shiva Raman raman.shi...@gmail.com 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