Re: root hints operation
On 2015-11-17 04:21, Ray Bellis wrote: On 17/11/2015 02:09, Grant Taylor wrote: On 11/16/2015 06:56 PM, /dev/rob0 wrote: You either specify a hints file to use, or use the compiled-in root hints. Interesting. I was not aware that it was an exclusive or type situation. It's important that they're exclusive - it would be very much harder to build an isolated test bed (with "fake" root hints) if BIND insisted on always trying to reach all of the compiled-in root hints. ... Or a real root hints file that differed from the compiled-in version, either in the current case (where there is a lot of overlap so it actually wouldn't matter that much) or for a private internet (lower-case 'i') with no overlap. Joe Yao ___ 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: root hints operation
No default route to Internet, internal-root architecture; when you think this through, it's pretty obvious that the ability to explicitly specify "hints" is a mandatory feature of any enterprise-strength DNS product. - Kevin -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Joseph S D Yao Sent: Tuesday, November 17, 2015 10:25 AM To: Ray Bellis Cc: bind-users@lists.isc.org Subject: Re: root hints operation On 2015-11-17 04:21, Ray Bellis wrote: > On 17/11/2015 02:09, Grant Taylor wrote: >> On 11/16/2015 06:56 PM, /dev/rob0 wrote: >>> You either specify a hints file to use, or use the compiled-in root >>> hints. >> >> Interesting. I was not aware that it was an exclusive or type >> situation. > > It's important that they're exclusive - it would be very much harder > to build an isolated test bed (with "fake" root hints) if BIND > insisted on always trying to reach all of the compiled-in root hints. ... Or a real root hints file that differed from the compiled-in version, either in the current case (where there is a lot of overlap so it actually wouldn't matter that much) or for a private internet (lower-case 'i') with no overlap. Joe Yao ___ 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 ___ 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: root hints operation
On 11/17/2015 03:02 PM, Dave Warren wrote: Or, the IP formerly used as a root server could turn malicious and start offering an alternate response. This would only impact resolvers that had outdated root hints, and also happened to try that particular IP first, but it's at least a theoretical risk. I read that the old IP that H-root is currently using will stay under the Army's control and will never be used for a DNS server again. Does anyone know if any of the other root servers that have changed their address have similarly quarantined the old IPs? -- Grant. . . . unix || die ___ 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: root hints operation
On 11/17/2015 03:22 PM, Mark Andrews wrote: Given the root zone is signed and most of the TLD's are also signed there is little a rogue operator can do besides causing a DoS if you validate the returned answers. This quite from Twitter seems appropriate: DNSSEC only protects you from getting bad answers. If someone wants you to get no answers at all then DNSSEC cannot help. I think it would be possible for a rogue operator to completely hide DNSSEC related records (NODATA) and revert to pre-DNSSEC DNS. Thus it would then be possible to do some nefarious things. I think the only thing that would help thwart this type of behavior is for clients to do DNSSEC validation themselves. (It's my understanding that most do not.) -- Grant. . . . unix || die ___ 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: root hints operation
On 11/17/2015 02:15 AM, Cathy Almond wrote: If someone *could* maliciously replace a file on your DNS server with a blank one, you have more problems than just a blank root hints file don't you? Very likely. But not guaranteed. }:-> -- Grant. . . . unix || die ___ 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: root hints operation
On 11/17/2015 02:21 AM, Ray Bellis wrote: It's important that they're exclusive - it would be very much harder to build an isolated test bed (with "fake" root hints) if BIND insisted on always trying to reach all of the compiled-in root hints. Valid point. Thanks Ray. Otherwise, I might be tempted to leverage some network black magic. -- Grant. . . . unix || die ___ 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: root hints operation
On 11/17/2015 04:10 PM, Darcy Kevin (FCA) wrote: No default route to Internet, internal-root architecture; when you think this through, it's pretty obvious that the ability to explicitly specify "hints" is a mandatory feature of any enterprise-strength DNS product. There is noting that prevents me from applying AS112 methodologies to the root DNS servers. (Network black magic.) -- Grant. . . . unix || die ___ 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: does bind depends on system DNS settings for lookup?
-Original Message- > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Dil Lee > Sent: Wednesday, 18 November 2015 3:42 PM > To: bind-users@lists.isc.org > Subject: does bind depends on system DNS settings for lookup? > Hi, > This is probably a dummy question. > My understand of bind in handling non-authoritative queries is: > 1) forward mode. It just forward the client queries to an upstream DNS > server, which is defined in "forwarders" directive. I don't think BIND forwards the request on at the packet level but proxies (creates a new request stuffing the question et al into the packet), but basically, yes. > 2) recursive mode. It actually start asking from root DNS server, then > 2nd level DNS server etc till it finally get an authoritative answer > for the host in question. This is correct. > Non of these modes seems to depends/relates to the system DNS settings > on the host which bind is running on, e.g. /etc/resolv.conf . AMIRITE? What you are talking about here is a "Stub Resolver"; the OS has sufficient libraries to ask a name server for a result. It has no concept of forwarding or recursing, just "Give me an answer please!". I believe any system that has an IP layer (and most likely others) has a stub resolver built into the core libraries. The stub resolver doesn't use BIND's libraries directly (thus no BIND needs to be installed to do DNS lookups as a client). > Regards, > Dil Stuart ___ 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: root hints operation
In message <564be747.40...@tnetconsulting.net>, Grant Taylor writes: > On 11/17/2015 03:22 PM, Mark Andrews wrote: > > Given the root zone is signed and most of the TLD's are also signed > > there is little a rogue operator can do besides causing a DoS if > > you validate the returned answers. > > This quite from Twitter seems appropriate: DNSSEC only protects you > from getting bad answers. If someone wants you to get no answers at all > then DNSSEC cannot help. As I said. It doesn't protect you from a Denial of Service. > I think it would be possible for a rogue operator to completely hide > DNSSEC related records (NODATA) and revert to pre-DNSSEC DNS. Thus it > would then be possible to do some nefarious things. > > I think the only thing that would help thwart this type of behavior is > for clients to do DNSSEC validation themselves. (It's my understanding > that most do not.) If your recursive server is validating then you are protected from a rogue root server. If your application is validating then you are protected from a rogue root server and a rogue recursive server. Mark > -- > Grant. . . . > unix || die > ___ > 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 -- 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
does bind depends on system DNS settings for lookup?
Hi, This is probably a dummy question. My understand of bind in handling non-authoritative queries is: 1) forward mode. It just forward the client queries to an upstream DNS server, which is defined in "forwarders" directive. 2) recursive mode. It actually start asking from root DNS server, then 2nd level DNS server etc till it finally get an authoritative answer for the host in question. Non of these modes seems to depends/relates to the system DNS settings on the host which bind is running on, e.g. /etc/resolv.conf . AMIRITE? Regards, Dil ___ 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: root hints operation
On 17/11/2015 02:31, Grant Taylor wrote: ... > The idea that a (maliciously) blank root.hints file would prevent BIND > from using the compiled in version is new to me. If someone *could* maliciously replace a file on your DNS server with a blank one, you have more problems than just a blank root hints file don't you? ___ 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: root hints operation
On 17/11/2015 02:09, Grant Taylor wrote: > On 11/16/2015 06:56 PM, /dev/rob0 wrote: >> You either specify a hints file to use, or use the compiled-in root >> hints. > > Interesting. I was not aware that it was an exclusive or type situation. It's important that they're exclusive - it would be very much harder to build an isolated test bed (with "fake" root hints) if BIND insisted on always trying to reach all of the compiled-in root hints. Ray ___ 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: root hints operation
On 2015-11-17 14:13, Mark Andrews wrote: In message <564ba3e3.9060...@hireahit.com>, Dave Warren writes: On 2015-11-16 18:09, Grant Taylor wrote: It's my understanding that ALL of the root servers would have to change all of their addresses at the same time for DNS to be impacted. Or, the IP formerly used as a root server could turn malicious and start offering an alternate response. This would only impact resolvers that had outdated root hints, and also happened to try that particular IP first, but it's at least a theoretical risk. Which is why those addresses get held back from reassignment. It is a known risk that is mitigated. Understood and agreed, there's little real-world risk, but it's important to understand that this risk is mitigated by policy, not by technology. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ 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: root hints operation
In message <564ba3e3.9060...@hireahit.com>, Dave Warren writes: > On 2015-11-16 18:09, Grant Taylor wrote: > > It's my understanding that ALL of the root servers would have to > > change all of their addresses at the same time for DNS to be impacted. > > Or, the IP formerly used as a root server could turn malicious and start > offering an alternate response. This would only impact resolvers that > had outdated root hints, and also happened to try that particular IP > first, but it's at least a theoretical risk. Which is why those addresses get held back from reassignment. It is a known risk that is mitigated. > -- > Dave Warren > http://www.hireahit.com/ > http://ca.linkedin.com/in/davejwarren > > > ___ > 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 -- 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: root hints operation
In message <564ba6e9.2050...@hireahit.com>, Dave Warren writes: > On 2015-11-17 14:13, Mark Andrews wrote: > > In message <564ba3e3.9060...@hireahit.com>, Dave Warren writes: > >> On 2015-11-16 18:09, Grant Taylor wrote: > >>> It's my understanding that ALL of the root servers would have to > >>> change all of their addresses at the same time for DNS to be impacted. > >> Or, the IP formerly used as a root server could turn malicious and start > >> offering an alternate response. This would only impact resolvers that > >> had outdated root hints, and also happened to try that particular IP > >> first, but it's at least a theoretical risk. > > Which is why those addresses get held back from reassignment. It is a > > known risk that is mitigated. > > Understood and agreed, there's little real-world risk, but it's > important to understand that this risk is mitigated by policy, not by > technology. Given the root zone is signed and most of the TLD's are also signed there is little a rogue operator can do besides causing a DoS if you validate the returned answers. > -- > Dave Warren > http://www.hireahit.com/ > http://ca.linkedin.com/in/davejwarren > > -- 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
