bind-users Digest, Vol 2230, Issue 1

Harshith Mulky harshith.mulky at outlook.com
Wed Oct 21 08:01:47 UTC 2015


Hello John,

1.) Are these devices some type of VoIP device?  I've seen many novel DNS based
      scenarios used for VoIP before.[Harshith] yes, they are VOIP devices which use "lwresd" to talk to external DNS Servers
 2.) I assume the path has been sniffed, are other records used as well, say SRV?
[Harshith] Yes we sniffed, SRV not used

Is there any concept of DNS PROBE?

I guess this wasn't a DNS question specifically and more on lwresd daemon.

Sorry to have posted a wrong question

Thanks
Harshith






From: John.Woodworth at CenturyLink.com
To: harshith.mulky at outlook.com; bind-users at lists.isc.org
CC: John.Woodworth at CenturyLink.com
Subject: RE: bind-users Digest, Vol 2230, Issue 1
Date: Wed, 21 Oct 2015 07:48:16 +0000











>

> From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Harshith Mulky
> Sent: Tuesday, October 20, 2015 10:50 AM
> To: bind-users at lists.isc.org
> Subject: RE: bind-users Digest, Vol 2230, Issue 1
>

> No Mark, This is not a question I am asked to answer for some course
>

> We have an implementation where, once the DNS Servers are down, The Client
> (Our device) Blacklists the IP address of DNS Servers for some period of Time
> It can only whitelist the server when it receives periodic Responses to a NAPTR Request.
>

> What I did find was even though Our Client was able to send periodic NAPTR
> requests, we are unable to check what kind of NAPTR requests are sent out
 
 
Harshith, While I am new to the group I am not sure this is the right audience
for your question as it does not really pertain to bind or the DNS protocol.
 
Having said that I love a good puzzle and am curious so below are a couple follow-up
questions.
 
  1.) Are these devices some type of VoIP device?  I've seen many novel DNS based
      scenarios used for VoIP before.
  2.) I assume the path has been sniffed, are other records used as well, say SRV?
  3.) Not sure why a particular record would be used to determine availability as
      really any RR could serve for this (including made up ones).
      [OK, not phrased in the form of a question]
  4.) What problem is being solved here?  Generally, with end devices DNS resolution
      starts at the top of its DNS resolver list and tries until it gets an answer
      or critical error (still an answer) within a timeout period.  The next query
      takes the same route and so on.  There are exceptions in implementation where
      statistics are maintained and its DNS resolver list is reordered accordingly
      but to blacklist and probe seems like a lot of wasted calories.
      For example:
        * What is the percentage of nameservers it would blacklist before
          it determines it is almost out of options?
        * Would it completely deny itself DNS service because of a few dropped
          packets or localized/ temporary network problems?
        * How many packet drops before it blacklists a nameserver?
        * How often does it probe for availability (whitelist)?
      Without knowing more this seemingly makes for a much more unreliable DNS
      experience.
 
Just curious,
John
 
>

> Hence my question,
> What Kind of messages are required by the client to be sent towards server to
> determine if the DNS IP is reachable or not?
 
 
I believe this may have already been answered but any query will work for
this purpose (including the "ANY" query).
 
 
>

> Thanks
> Harshith

>

 



This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately
 notify the sender by reply e-mail and destroy all copies of the communication and any attachments. 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20151021/2a47a510/attachment-0001.html>


More information about the bind-users mailing list