Re: Troubleshooting Information
On 8/28/15 9:19 AM, Bob McDonald wrote: It appears that receiving an NSID response depends on having server-id set in the options block. However, I'm seeing no way to restrict such queries. You don't have to set the server-id information to anything that an external entity would find interesting. Set the server-ids to 1, 2, 3, or binary blob 1, binary blob 2, binary blob 3 and you are set. The magic of NSID is that you are able to use it through load balancers, etc. Do a normal A record lookup, set the NSID bit and you still get the A record, but in addition, you get the server-id information from the server that actually responded to the request. Please remember that even if you are doing your best at hiding all of the information that is kept in the easter egg zones, there are other ways to determine the type/location/whatever of your nameservers. fpdns may be undermining almost all of your efforts. And, my last input of the day: Script kiddies are going to shotgun attacks against your nameserver - they don't care about the version data provided. Targeted attacks are going to be much more deliberate and they are going to be much more intelligent than basing the attack on the chaos data provided by your nameserver - They don't care about the version data provided. AlanC -- When I do still catch the odd glimpse, it's peripheral; mere fragments of mad-doctor chrome, confining themselves to the corner of the eye. signature.asc Description: OpenPGP digital 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: Troubleshooting Information
It appears that receiving an NSID response depends on having server-id set in the options block. However, I'm seeing no way to restrict such queries. regards, Bob On Fri, Aug 28, 2015 at 7:48 AM, Bob McDonald bmcdonal...@gmail.com wrote: No, and there seems to be sparse documentation of the use of NSID in troubleshooting. I'm all ears. I would. however, like to restrict queries to inside networks/users and negate access to that data from the outside altogether. TIA, Bob Alan Clegg wrote: Has anyone recommended doing debugging via NSID instead of the CH class data? ___ 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: Troubleshooting Information
No, and there seems to be sparse documentation of the use of NSID in troubleshooting. I'm all ears. I would. however, like to restrict queries to inside networks/users and negate access to that data from the outside altogether. TIA, Bob Alan Clegg wrote: Has anyone recommended doing debugging via NSID instead of the CH class data? ___ 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 Negative Caching
Is that really still true? I thought that use of the Minimum field went away when it was changed to be the negative cache TTL. Barry, Yes, it’s still true. If you don’t set a default TTL, then the last field of the SOA record does double duty as both a default TTL and a negative caching TTL. And no RFC has ever updated its name. Chris Buxton ___ 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 Negative Caching
On 2015-08-28 14:15, Darcy Kevin (FCA) wrote: As you pointed out (correctly), this isn't an issue which affects anything that goes on the wire, e.g. master-slave replication via AXFR/IXFR, since, on the wire the TTL is always included with the RR. It's only an issue for how the zone files are managed on the master. My opinion: named on the master should reject illegal zone files. Agreed. Could you please cite where in RFC 2308 $TTL is a MUST, or even a SHOULD? Or was this made mandatory elsewhere? RFC 2308 is clear on what should happen after a $TTL directive, but seems silent on how to handle resource records prior to, or in the absence of a $TTL directive, but it does note that the minimum TTL field has traditionally had three uses: First: as a minimum. Result? is hereby deprecated Second: Result? No change in status. Third: The remaining of the current meanings, of being the TTL to be used for negative responses, is the new defined meaning of the SOA minimum field. -- This almost goes far enough to depreciate the second, but given the explicit language depreciating the first, I would think that the author would have used similar language had they intended to depreciate the second. The closest we get is section 4, Where a server does not require RRs to include the TTL value explicitly, it should provide a mechanism, not being the value of the MINIMUM field of the SOA record, from which the missing TTL values are obtained. That's a should (not even a SHOULD), but in the absence of this specified minimum (either by lack of implementation, or lack of configuration), the SOA MINIMUM field would seem to be better than failing outright. It's perhaps only an issue for some homebrew zonefile-creation scripts that were written a long time ago, and where the administrators have been systematically ignoring the no TTL specified; using SOA MINTTL instead errors in their logs, every time named loads or reloads the zones. I'm not suggesting I'm going to start writing or recommending zone files without a $TTL directive, or that this is even a big deal in the real world, but I'm struggling to find a case where the absence of a $TTL directive would result in a zone file being illegal, and so falling back on the SOA's minimum field would seem to be a more sane choice than making one up or refusing the zone, if only as a nod to the legacy use of this field. -- 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: Identify source of rndc reconfig command?
Thank you all for your help! I found that the reconfig command was called by a script executed by wide-dhcpv6-client. In wheezy, this script was called once when the ipv6 address of the public ppp interface changed, in Jessie it was called every 30 minutes for whatever reason. Fixed that. Cheers, Robert Am Montag, den 24.08.2015, 23:01 +0200 schrieb Robert Senger: Hi all, after upgrading from Debian Wheezy to Jessie, bind9 receives rndc reconfig commands every 30 minutes. I've never seen this before. Some of my own scripts run rndc restart/reload after fiddling with network interfaces, but none of these is the source of the observed 30 minutes interval. There are also no cron jobs. In the bind9 logs I see this: 24-Aug-2015 22:53:43.431 general: info: received control channel command 'reconfig' 24-Aug-2015 22:53:43.458 general: info: loading configuration from '/etc/bind/named.conf' ... [more than 350 lines reconfig log] Running tcpdump on the lo interface gives me this: root@prokyon:/etc/bind# tcpdump -i lo port 953 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes 21:23:35.071602 IP localhost.48466 localhost.953: Flags [S], seq 3862717043, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 0,nop,wscale 5], length 0 21:23:35.071699 IP localhost.953 localhost.48466: Flags [S.], seq 2391140312, ack 3862717044, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 196635776,nop,wscale 5], length 0 21:23:35.071821 IP localhost.48466 localhost.953: Flags [.], ack 1, win 1366, options [nop,nop,TS val 196635776 ecr 196635776], length 0 21:23:35.075355 IP localhost.48466 localhost.953: Flags [P.], seq 1:148, ack 1, win 1366, options [nop,nop,TS val 196635777 ecr 196635776], length 147 21:23:35.075435 IP localhost.953 localhost.48466: Flags [.], ack 148, win 1399, options [nop,nop,TS val 196635777 ecr 196635777], length 0 21:23:35.115513 IP localhost.953 localhost.48466: Flags [P.], seq 1:180, ack 148, win 1399, options [nop,nop,TS val 196635787 ecr 196635777], length 179 21:23:35.115583 IP localhost.48466 localhost.953: Flags [.], ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 0 21:23:35.116084 IP localhost.48466 localhost.953: Flags [P.], seq 148:320, ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 172 21:23:35.116130 IP localhost.953 localhost.48466: Flags [.], ack 320, win 1433, options [nop,nop,TS val 196635787 ecr 196635787], length 0 21:23:37.092444 IP localhost.953 localhost.48466: Flags [P.], seq 180:363, ack 320, win 1433, options [nop,nop,TS val 196636281 ecr 196635787], length 183 21:23:37.094097 IP localhost.48466 localhost.953: Flags [F.], seq 320, ack 363, win 1433, options [nop,nop,TS val 196636281 ecr 196636281], length 0 21:23:37.130367 IP localhost.953 localhost.48466: Flags [.], ack 321, win 1433, options [nop,nop,TS val 196636291 ecr 196636281], length 0 21:23:37.829134 IP localhost.953 localhost.48466: Flags [F.], seq 363, ack 321, win 1433, options [nop,nop,TS val 196636465 ecr 196636281], length 0 21:23:37.829288 IP localhost.48466 localhost.953: Flags [.], ack 364, win 1433, options [nop,nop,TS val 196636465 ecr 196636465], length 0 Is there a way to identify the source of these reconfig commands? It's really annoying as it messes up the log with 350 useless lines every 30 minutes. Thanks! Robert -- Robert Senger ___ 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 Negative Caching
Negative-caching TTL and regular TTL have little to do with each other; it's not a reasonable assumption that one should stand in as a default for the other. I know analogies are frequently dangerous, but to me, that's kind of like saying that the amount of time that normally elapses between replacing one's automobile with a newer vehicle, can be safely assumed to be equal to the amount of time one could go without an automobile at all. The two things are related, of course (in the analogy, they're both about automobiles), but it would be foolish to assume that one time interval is the same as the other. One pertains to the *existence* of something, that needs to be periodically refreshed; the other refers to the duration of an *absence* of something. As you pointed out (correctly), this isn't an issue which affects anything that goes on the wire, e.g. master-slave replication via AXFR/IXFR, since, on the wire the TTL is always included with the RR. It's only an issue for how the zone files are managed on the master. My opinion: named on the master should reject illegal zone files. Note that this is a non-issue if Dynamic Update is being used to manage zones (since then named writes out the zone file), or if a commercial-grade DNS management system is the thing that's generating the zone files (since they should all be compliant to RFC 2308 by now; if not, sue the manufacturer for a product defect). It's perhaps only an issue for some homebrew zonefile-creation scripts that were written a long time ago, and where the administrators have been systematically ignoring the no TTL specified; using SOA MINTTL instead errors in their logs, every time named loads or reloads the zones. - Kevin -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas Sent: Friday, August 28, 2015 3:49 PM To: bind-users@lists.isc.org Subject: Re: DNS Negative Caching On 28.08.15 17:32, Darcy Kevin (FCA) wrote: RFC 2308 said that the use of the last field of the SOA to set negative-caching TTL is the new defined meaning of the SOA minimum field. So you can *call* it minimum, but it is *actually* supposed to function as something else... Eventually I hope BIND will conform to the spirit of RFC 2308 and stop using the last field of the SOA to set the default TTL, as a fallback in scenarios where the file would otherwise be illegal (i.e. the first RR has no explicit TTL set, and there is no $TTL directive preceding it). RFC 2308 is so old, that if it were a person, it would be legal to buy cigarettes in some parts of the world. It's long past time for folks to get with the program. what would you expect bind to do in such case, refuse the zone? The minimum value is safe default in most cases. Note that is only matters on masters, the XFER slaves see the ttl within each record... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. One OS to rule them all, One OS to find them, One OS to bring them all and into darkness bind them ___ 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: DNSSEC ZSK rollover
On Fri, Aug 28, 2015 at 07:24:23PM +0200, Robert Senger wrote: Is that the intended behaviour, or do I miss a point to get the zones resigned in one single action (and transfered with one single IXFR) rather than getting each RR resigned separately? It is intentional; it spreads out the work of resigning over a longer period of time to reduce the load on the server. (And a lot of people prefer smaller IXFRs anyway.) You can adjust the resigning interval, or force a full resign with rndc sign. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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 Negative Caching
In article mailman.2601.1440783131.26362.bind-us...@lists.isc.org, Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote: What's in a name? :-) RFC 2308 said that the use of the last field of the SOA to set negative-caching TTL is the new defined meaning of the SOA minimum field. So you can *call* it minimum, but it is *actually* supposed to function as something else... Eventually I hope BIND will conform to the spirit of RFC 2308 and stop using the last field of the SOA to set the default TTL, as a fallback in scenarios where the file would otherwise be illegal (i.e. the first RR has no explicit TTL set, and there is no $TTL directive preceding it). RFC 2308 is so old, that if it were a person, it would be legal to buy cigarettes in some parts of the world. It's long past time for folks to get with the program. Does the RFC specify some other default TTL if there's no $TTL directive? If not, the software needs to do something, and using the old method for compatibility is as good anything else (on the assumption that anyone who didn't put $TTL in the file was depending on this use of the SOA record). -- Barry Margolin Arlington, MA ___ 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 Negative Caching
On 28.08.15 17:32, Darcy Kevin (FCA) wrote: RFC 2308 said that the use of the last field of the SOA to set negative-caching TTL is the new defined meaning of the SOA minimum field. So you can *call* it minimum, but it is *actually* supposed to function as something else... Eventually I hope BIND will conform to the spirit of RFC 2308 and stop using the last field of the SOA to set the default TTL, as a fallback in scenarios where the file would otherwise be illegal (i.e. the first RR has no explicit TTL set, and there is no $TTL directive preceding it). RFC 2308 is so old, that if it were a person, it would be legal to buy cigarettes in some parts of the world. It's long past time for folks to get with the program. what would you expect bind to do in such case, refuse the zone? The minimum value is safe default in most cases. Note that is only matters on masters, the XFER slaves see the ttl within each record... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. One OS to rule them all, One OS to find them, One OS to bring them all and into darkness bind them ___ 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 Negative Caching
In article mailman.2604.1440796547.26362.bind-us...@lists.isc.org, Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote: Negative-caching TTL and regular TTL have little to do with each other; it's not a reasonable assumption that one should stand in as a default for the other. True, but that's water long under the bridge. Note that if a server is authoritative-only, caching is mostly irrelevant, so the negative cache TTL doesn't much apply. In this case, the SOA Minimum is just being used as the default TTL. My opinion: named on the master should reject illegal zone files. As far as I can tell, nothing in RFC 2308 says that $TTL is required. I don't even see a SHOULD, let alone a MUST. Is there a later RFC that adds this requirement? If not, then a zone file without $TTL is legal. And for backward compatibility, it should continue to use the SOA Minimum field as the default TTL. -- Barry Margolin Arlington, MA ___ 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
