Re: Local Slave copy of root zone
Doug Barton wrote: > > How, specifically, is DNSSEC affected by the validating resolver having a > local copy of the root zone? If the local root zone gets corrupted somehow (maliciously or otherwise) the usual setup cannot detect a problem, but it'll cause DNSSEC validation failures downstream. The normal resolver / validator algorithm is more robust. The new mirror zone code validates the root zone before installing it, which at least allows it to detect a problem; I have not examined it closely enough to see how hard it tries to recover by xfering the zone from a different root server, or if it just falls back to normal resolution. Tony. -- f.anthony.n.finchhttp://dotat.at/ Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Westerly, backing southerly later, 4 or 5, occasionally 6 later in Fair Isle. Moderate, occasionally slight. Showers then rain. Good, becoming moderate or poor. ___ 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: Local Slave copy of root zone
On 08/20/2018 05:23 AM, Tony Finch wrote: If the local root zone gets corrupted somehow (maliciously or otherwise) the usual setup cannot detect a problem, but it'll cause DNSSEC validation failures downstream. The normal resolver / validator algorithm is more robust. The new mirror zone code validates the root zone before installing it, which at least allows it to detect a problem; I have not examined it closely enough to see how hard it tries to recover by xfering the zone from a different root server, or if it just falls back to normal resolution. Thank you for that explanation. It explains why it's potentially dangerous to blindly slave the root zone for general use by clients on a local recursive resolver. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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: nslookup oddities (Was: SRV record not working)
On 8/19/18, Mark Andrews wrote: > nslookup applies the search list by default and doesn’t stop on a NODATA > response. > > Some versions of nslookup have been modified by OS vendors to use /etc/hosts > for address lookups. > > nslookup doesn’t display the entire response by default. I learned something :) Thank you Not that I know the implications of "doesn’t stop on a NODATA response" but hopefully that can be remedied. wrt the search list, that's why I got in the habit of always typing the trailing dot. I've never seen that fail, but 'set nosearch' is supposed to do the same thing. 'set debug' and 'set d2' displays lots, but I never checked to see if it was the entire response or no So... it seems like the bottom line is that dig is better but nslookup ain't all that bad Thanks Lee >> On 20 Aug 2018, at 12:28 pm, Lee wrote: >> >> On 8/19/18, Doug Barton wrote: >>> On 08/19/2018 12:11 PM, Lee wrote: On 8/18/18, Doug Barton wrote: >>> > nslookup uses the local resolver stub. That's fine, if that's what you > want/need to test. If you want to test specific servers, or what is > visible from the Internet, etc. dig is the right tool, as the answers > you get from nslookup cannot be guaranteed to be directly related to > the > question you asked. Could you expand on that a bit please? I thought nslookup was pretty much equivalent to dig @ the exception being that nslookup looks for a & records and dig just looks for a records >>> >>> Nope. Depending on what operating system you're on, what version of >>> nslookup you have, how you format your query, and how the system is >>> configured; even telling nslookup to query a specific server may not get >>> you the answer you're looking for. >> >> That's still awfully vague. Do you have any examples of >>nslookup >> returning bad information? >> >>> If you want to know what answer your stub resolver is going to return >>> for a given query, nslookup is a great tool. Although, if you just need >>> to know what address record you'll get back, ping works just as well. >> >> ping just shows one address; "nslookup www.yahoo.com" shows all of them >> >>> If you want to really debug DNS you need to learn to use dig, and >>> understand the output. >> >> Agreed. If you're serious about debugging DNS you needs to learn dig. >> But the assertion is > ... the answers > you get from nslookup cannot be guaranteed to be directly related to > the > question you asked. >> >> so I'm wondering how, or under what circumstances, nslookup returns >> invalid information. >> >> Thanks >> Lee ___ 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: nslookup oddities (Was: SRV record not working)
Lee wrote: > > So... it seems like the bottom line is that dig is better but nslookup > ain't all that bad Be careful though, all bets are off if you find yourself using something that claims to be nslookup but which isn't the BIND9 version. Tony. -- f.anthony.n.finchhttp://dotat.at/ North Rockall, Malin, Hebrides, Bailey, Fair Isle, Faeroes: Variable 3 or 4, becoming southeasterly 4 or 5, then cyclonic, mainly southerly or southwesterly later, 5 to 7. Moderate, occasionally rough later. Fair then rain with fog patches. Good becoming moderate, occasionally very poor. ___ 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: Local Slave copy of root zone
On 08/20/2018 09:00 AM, Grant Taylor via bind-users wrote: On 08/20/2018 05:23 AM, Tony Finch wrote: If the local root zone gets corrupted somehow (maliciously or otherwise) the usual setup cannot detect a problem, but it'll cause DNSSEC validation failures downstream. The normal resolver / validator algorithm is more robust. The new mirror zone code validates the root zone before installing it, which at least allows it to detect a problem; I have not examined it closely enough to see how hard it tries to recover by xfering the zone from a different root server, or if it just falls back to normal resolution. Thank you for that explanation. It explains why it's potentially dangerous to blindly slave the root zone for general use by clients on a local recursive resolver. No, it doesn't do that at all. It may be true that the new mirror zone code does awesome things to make sure that the slaved zone is identical to the master's, I don't know, I haven't seen it. But that doesn't mean that slaving a zone, any zone, including the root, is "dangerous." If slaving zones is dangerous, the DNS is way more fragile than it already is. The DNSSEC validation errors that Tony references are self-healing, in that if the validating resolver stops validating things, the operator is hopefully going to notice that, and take steps to fix it. And I have always said that you should not be slaving the root unless you already have a good mechanism for making sure that said slaving isn't failing. (In other words, don't go into this, or any other configuration blind.) I am certainly open to the new mirror zone software doing awesome things, don't get me wrong. But don't call something "dangerous" that lots of people have already been using successfully for over 15 years. ___ 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: nslookup oddities (Was: SRV record not working)
On 08/20/2018 10:14 AM, Lee wrote: On 8/19/18, Mark Andrews wrote: nslookup applies the search list by default and doesn’t stop on a NODATA response. Some versions of nslookup have been modified by OS vendors to use /etc/hosts for address lookups. nslookup doesn’t display the entire response by default. I learned something :) Thank you Not that I know the implications of "doesn’t stop on a NODATA response" but hopefully that can be remedied. wrt the search list, that's why I got in the habit of always typing the trailing dot. I've never seen that fail, but 'set nosearch' is supposed to do the same thing. 'set debug' and 'set d2' displays lots, but I never checked to see if it was the entire response or no So... it seems like the bottom line is that dig is better but nslookup ain't all that bad Lee, Messages like this, and the one you sent me privately, are the reason that I usually don't even bother replying to messages on this list. I don't say that to denigrate you. I say it in the hopes that someone, maybe even you, will learn from your mistake. Your "bottom line" completely misses basically everything that's been said in this thread. No one has made any statement about nslookup being "bad," or "worse" than any other tool. I have clearly stated the contexts in which the two tools are more or less suited for a given situation, and given reasons why. Others have expanded on those reasons. If you still don't understand why, at least try to understand the when and how. Go back and re-read the thread. Look up the terms that you don't understand. You can even ask reasonable, specific questions to the effect of, "I looked up term XYZ but didn't understand how the zig interacts with the zag, can someone explain that to me?" In other words, do SOMETHING to help yourself. Don't complain that no one worked hard enough to make you understand something that you seem to be working so hard to misunderstand. Good luck, Doug ___ 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
