RE: bind-users Digest, Vol 2230, Issue 1
> > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Harshith Mulky > Sent: Tuesday, October 20, 2015 10:50 AM > To: bind-users@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. ___ 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: bind-users Digest, Vol 2230, Issue 1
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.woodwo...@centurylink.com To: harshith.mu...@outlook.com; bind-users@lists.isc.org CC: john.woodwo...@centurylink.com Subject: RE: bind-users Digest, Vol 2230, Issue 1 Date: Wed, 21 Oct 2015 07:48:16 + > > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Harshith Mulky > Sent: Tuesday, October 20, 2015 10:50 AM > To: bind-users@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. ___ 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
Why two lookups for a CNAME?
I'm sure there's a good, simple reason for this, I just can't seem to find the answer searching on the Internet. Why does named perform a lookup for the A record when its IP is returned with the CNAME in the first answer? Using dig, I find play.google.com is a CNAME for play.l.google.com. When asked to resolve it, named will first look for play.google.com. The result will include the CNAME and the IP of the A record. Named then makes a second request to resolve the A record. Thanks in advance, Steve.___ 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: Why two lookups for a CNAME?
Because the purpose of DNS primarily is to equate a name with an IP as applications talk to IPs not to names. When you have a CNAME you’re equating one name with another name. That other name then has to be looked up so the application knows what IP access. This saves time if you have multiple CNAMES to the same A record in that when you update DNS you only have to update that one A record. You don’t have to use CNAMES to go to same IP – you could make each record an A record pointing to the same IP. You’d then have to be sure you updated all the A records using that IP if you decided to change it to something else later (e.g. if you changed ISPs). Obviously there is a small performance cost in CNAMES which is why you don’t want to have a CNAME to another CNAME because that results in 3 lookups. For most applications the single CNAME isn’t an issue but on occasion it is so you go the A record route instead. From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Steve Arntzen Sent: Wednesday, October 21, 2015 4:33 PM To: bind-users Subject: Why two lookups for a CNAME? I'm sure there's a good, simple reason for this, I just can't seem to find the answer searching on the Internet. Why does named perform a lookup for the A record when its IP is returned with the CNAME in the first answer? Using dig, I find play.google.com is a CNAME for play.l.google.com. When asked to resolve it, named will first look for play.google.com. The result will include the CNAME and the IP of the A record. Named then makes a second request to resolve the A record. Thanks in advance, Steve. ___ 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: Why two lookups for a CNAME?
Thank you Jeff. I was just wondering why, when the IP comes back with the first response, does named ask again? Is it just being literal (like me) or will it not always get the IP in the first request (depending on the DNS server)? Steve. > On October 21, 2015 at 3:42 PM "Lightner, Jeff" > wrote: > > > Because the purpose of DNS primarily is to equate a name with an IP as > applications talk to IPs not to names. When you have a CNAME you’re equating > one name with another name. That other name then has to be looked up so the > application knows what IP access. > > > > This saves time if you have multiple CNAMES to the same A record in that > when you update DNS you only have to update that one A record. You don’t have > to use CNAMES to go to same IP – you could make each record an A record > pointing to the same IP. You’d then have to be sure you updated all the A > records using that IP if you decided to change it to something else later > (e.g. if you changed ISPs). > > > > Obviously there is a small performance cost in CNAMES which is why you > don’t want to have a CNAME to another CNAME because that results in 3 > lookups. For most applications the single CNAME isn’t an issue but on > occasion it is so you go the A record route instead. > > > > > > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Steve Arntzen > Sent: Wednesday, October 21, 2015 4:33 PM > To: bind-users > Subject: Why two lookups for a CNAME? > > > > I'm sure there's a good, simple reason for this, I just can't seem to find > the answer searching on the Internet. > > > > Why does named perform a lookup for the A record when its IP is returned > with the CNAME in the first answer? > > > > Using dig, I find play.google.com is a CNAME for play.l.google.com. > > > > When asked to resolve it, named will first look for play.google.com. The > result will include the CNAME and the IP of the A record. > > > > Named then makes a second request to resolve the A record. > > > > Thanks in advance, > > > > Steve. > ___ 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: Why two lookups for a CNAME?
To prevent cache poisoning via cnames. It it simpler to always lookup the target of the cname that to figure out if we would accepted the following data. server A has zones foo.example and bar.example configured server B has zone bar.example configured bar.example is only delegated to server B of the two server above. The is a cname from www.foo.example -> www.bar.example Server A return a complete answer but the www.bar.example data is from the wrong zone instance. This happens accidentally in real life. Mark In message <1401468033.15948.1445459552099.javamail.vpopm...@atl4oxapp02pod1.mg t.hosting.qts.netsol.com>, Steve Arntzen writes: > > I'm sure there's a good, simple reason for this, I just can't seem to find th > e > answer searching on the Internet. > > > Why does named perform a lookup for the A record when its IP is returned with > the CNAME in the first answer? > > > Using dig, I find play.google.com is a CNAME for play.l.google.com. > > > When asked to resolve it, named will first look for play.google.com. The res > ult > will include the CNAME and the IP of the A record. > > > Named then makes a second request to resolve the A record. > > > Thanks in advance, > > > Steve. > --=_Part_15947_1241356502.1445459552087 > MIME-Version: 1.0 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: 7bit > > http://www.w3.org/T > R/xhtml1/DTD/xhtml1-strict.dtd"> > > http://www.w3.org/1999/xhtml";> > > I'm sure there's a good, simple reason for this, I j > ust can't seem to find the answer searching on the Internet. p>Why does named perform a lookup for the A record when its IP is returned > with the CNAME in the first answer?Using dig, I find play. > google.com is a CNAME for play.l.google.com.When asked to r > esolve it, named will first look for play.google.com. The result will i > nclude the CNAME and the IP of the A record.Named then make > s a second request to resolve the A record.Thanks in advanc > e,Steve. > --=_Part_15947_1241356502.1445459552087-- > > --===7115022951714415033== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > ___ > 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 > --===7115022951714415033==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Why two lookups for a CNAME?
On Wed, 2015-10-21 at 20:42 +, Lightner, Jeff wrote: > Because the purpose of DNS primarily is to equate a name with an IP as > applications talk to IPs not to names. When you have a CNAME you’re > equating one name with another name. That other name then has to be > looked up so the application knows what IP access. This doesn't answer the OPs question (which is a good one). He's saying that the required IP address has *already been returned* in the first response, so why is a second query made? When I use dig to do a lookup of a cname, it makes only one query: ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> www.angihigh.com.au [...] ;; ANSWER SECTION: www.angihigh.com.au/ ... CNAME angihigh.com.au. angihigh.com.au. ... A 27.121.64.62 [...] Maybe the application mentioned by the OP is not a smart as dig. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 ___ 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: Why two lookups for a CNAME?
Makes sense. Better safe than sorry. Thanks, Steve. > > On October 21, 2015 at 4:01 PM Mark Andrews wrote: > > > > To prevent cache poisoning via cnames. It it simpler to always > lookup the target of the cname that to figure out if we would > accepted the following data. > > server A has zones foo.example and bar.example configured > server B has zone bar.example configured > > bar.example is only delegated to server B of the two server above. > > The is a cname from www.foo.example -> www.bar.example > > Server A return a complete answer but the www.bar.example data is > from the wrong zone instance. This happens accidentally in real > life. > > Mark > > In message > <1401468033.15948.1445459552099.javamail.vpopm...@atl4oxapp02pod1.mg > t.hosting.qts.netsol.com>, Steve Arntzen writes: > > > > I'm sure there's a good, simple reason for this, I just can't seem to > > find th > > e > > answer searching on the Internet. > > > > > > Why does named perform a lookup for the A record when its IP is returned > > with > > the CNAME in the first answer? > > > > > > Using dig, I find play.google.com is a CNAME for play.l.google.com. > > > > > > When asked to resolve it, named will first look for play.google.com. The > > res > > ult > > will include the CNAME and the IP of the A record. > > > > > > Named then makes a second request to resolve the A record. > > > > > > Thanks in advance, > > > > > > Steve. > > --=_Part_15947_1241356502.1445459552087 > > MIME-Version: 1.0 > > Content-Type: text/html; charset=UTF-8 > > Content-Transfer-Encoding: 7bit > > > > > "http://www.w3.org/T > > R/xhtml1/DTD/xhtml1-strict.dtd"> > > > > http://www.w3.org/1999/xhtml";> > > > > I'm sure there's a good, simple reason for this, I j > > ust can't seem to find the answer searching on the > > Internet. > p>Why does named perform a lookup for the A record when its IP is > > returned > > with the CNAME in the first answer?Using dig, I find > > play. > > google.com is a CNAME for play.l.google.com.When asked > > to r > > esolve it, named will first look for play.google.com. The result will i > > nclude the CNAME and the IP of the A record.Named then > > make > > s a second request to resolve the A record.Thanks in > > advanc > > e,Steve. > > --=_Part_15947_1241356502.1445459552087-- > > > > --===7115022951714415033== > > Content-Type: text/plain; charset="us-ascii" > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > ___ > > 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 > > --===7115022951714415033==-- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ___ 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
