Help to identify Microsoft DNS version
Dear All, Can anyone help me how to find bind & microsoft DNS software version using dig or nslookup command remotely? Regards Babu___ 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
Is bind support conditionally resolution?
I am designing a big deploy system, which will implement via DNS. The demond is misc, one of them is conditionally resolve, which means that if one CDN node near unavailable, or latency increased significantly, no matter why, I want bind to give another second best result, which located in distant places. Is bind support this natively? Or I have to write external program? If bind doesn't support, is there any other DNS impletions I can try? ___ 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: NAPTR Catch-all
Hi, Okay, *. works perfectly, however, I need to limit the queries to specific numbers. As an example 0.0.1.0.9.6.4.1.2.7.2.domain1.com 3.8.6.2.7.4.7.2.8.7.2.domain2.net 8.1.5.1.0.5.3.7.8.7.2.domain3 As per above, the number portion [0-9].[0-9]... will need to be specific, while the domain portion .domain.tld will change based on the environment. I also tried *.8.1.5.1.0.5.3.7.8.7.2. which also did not work (as expected). Many thanks Doug On 2012/01/10 8:28 AM, Florian Weimer wrote: >> I did try the following: >> >> 7.7.7.5.2.1.4.4.9.9.8.1.2.* > The "*" wildcard must be the first label. ___ 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: NAPTR Catch-all
Hi, Okay, *. works perfectly, however, I need to limit the queries to specific numbers. As an example 0.0.1.0.9.6.4.1.2.7.2.domain1.com 3.8.6.2.7.4.7.2.8.7.2.domain2.net 8.1.5.1.0.5.3.7.8.7.2.domain3 As per above, the number portion [0-9].[0-9]... will need to be specific, while the domain portion .domain.tld will change based on the environment. Many thanks Doug On 2012/01/10 8:28 AM, Florian Weimer wrote: >> I did try the following: >> >> 7.7.7.5.2.1.4.4.9.9.8.1.2.* > The "*" wildcard must be the first label. ___ 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: NAPTR Catch-all
> I did try the following: > > 7.7.7.5.2.1.4.4.9.9.8.1.2.* The "*" wildcard must be the first label. ___ 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: NAPTR Catch-all
Hi, I did try the following: 7.7.7.5.2.1.4.4.9.9.8.1.2.* Which sadly did not work. Below is an example of queries that I would typically need to process. In all examples, the number will be the same, its just the domain portion that will change based on the environment: 7.7.7.5.2.1.4.4.9.9.8.1.2.domain1.com 7.7.7.5.2.1.4.4.9.9.8.1.2.domain2.com 7.7.7.5.2.1.4.4.9.9.8.1.2.domain3 (intentionally left this one without a .tld) 7.7.7.5.2.1.4.4.9.9.8.1.2.domain4 7.7.7.5.2.1.4.4.9.9.8.1.2.domain5 7.7.7.5.2.1.4.4.9.9.8.1.2.127.0.0.1 7.7.7.5.2.1.4.4.9.9.8.1.2.196.43.1.1 While the above is only a few examples and seems to be fairly simple to put together, the domains will change dramatically, which makes it quite an administrative task to keep building authoritative zones for each domain - thats why I was hoping it might be possible to achieve this via a wildcard. Many thanks Doug On 2012/01/09 9:43 PM, Florian Weimer wrote: >> 7.7.7.5.2.1.4.4.9.9.8.1.2.INNAPTR10010"u" "E2U+sip" >> "!(^.*$)!sip:2799820784000132" .; Testing > This isn't a wildcard, so it will not match as a wildcard. > > Can you provide a few example RRs which you want to synthesize using > wildcards? It's not clear (to me at least) what you're trying to do. > There is a good chance that you have to change the regexp part of the > NAPTR record. ___ 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
Bind to INADDR_ANY
Hi everyone, is binding to all interfaces at once already supported in bind9? I know named binds to each at-the-moment-available IP address but in HA environment with virtual interfaces a "rndc reload" is necessary for named to pick up a new interface, which leaves a bit of a window of unavailable service. Thank you for the answer, b. ___ 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: Exercising RFC 5011 rollovers
On Mon, Jan 09, 2012 at 09:40:51PM +, Chris Thompson wrote: > | If the resolver ever sees the DNSKEY RRSet without the new key but > | validly signed, it stops the acceptance process for that key and > | resets the acceptance timer. > > What BIND does is to retain the entry for the new key in managed-keys.bind > but every time it notices that it is no longer published it sets the > KEYDATA.addhd field 30 days in the future. Thus it will never get accepted > as a trust anchor. > > That seems to satisfy the letter of the law, but it does mean that > managed-keys.bind remains cluttered with such keys. You have a point. I don't remember making that particular design decision, but I probably just didn't think about it. "Reset the acceptance timer" implies the existence of a timer; if I'd deleted the key, there wouldn't be a timer to reset. :) Feel free to open a ticket at bind9-b...@isc.org. It's not likely to be a particularly high-priority fix, though. -- 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
BIND 9.9.0rc1 is now available
Introduction BIND 9.9.0rc1 is the first release candidate for BIND 9.9. This document summarizes changes from BIND 9.8 to BIND 9.9. Please see the CHANGES file in the source code release for a complete list of all changes. Download The latest versions of BIND 9 software can always be found on our web site at http://www.isc.org/downloads/all. There you will find additional information about each release, source code, and pre-compiled versions for Microsoft Windows operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. Security Fixes - BIND 9 nameservers performing recursive queries could cache an invalid record and subsequent queries for that record could crash the resolvers with an assertion failure. [RT #26590] [CVE-2011-4313] New Features - NXDOMAIN redirection is now possible. This enables a resolver to respond to a client with locally-configured information when a query would otherwise have gotten an answer of "no such domain". This allows a recursive nameserver to provide alternate suggestions for misspelled domain names. Note that names that are in DNSSEC-signed domains are exempted from this when validation is in use. [RT #23146] - Improved scalability by using multiple threads to listen for and process queries. Previously named only listened for queries on one thread regardless of the number of overall threads used. [RT #22992] - Improves startup and reconfiguration time by allowing zones to load in multiple threads. [RT #25333] - Improves initial start-up and server reload time by increasing the default size of the hash table the configuration parser uses to keep track of loaded zones and allowing it to grow dynamically to better handle systems with large numbers of zones. [RT #26523] - Improves the startup time for an authoritative server with a large number of zones by making the zone task table of variable size rather than fixed size. This means that authoritative servers with many zones will be serving that zone data much sooner. [RT #24406] - The new "inline-signing" option, in combination with the "auto-dnssec" option that was introduced in BIND 9.7, allows named to sign zones completely transparently. Previously automatic zone signing only worked on master zones that were configured to be dynamic; now, it works on any master or slave zone. In a master zone with inline signing, the zone is loaded from disk as usual, and a second copy of the zone is created to hold the signed version. The original zone file is not touched; all comments remain intact. When you edit the zone file and reload, named detects the incremental changes that have been made to the raw version of the zone, and applies those changes to the signed version, adding signatures as needed. A slave zone with inline signing works similarly, except that instead of loading the zone from disk and then signing it, the slave transfers the zone from a master server and then signs it. This enables "bump in the wire" signing: a dedicated signing server acting as an intermediary between a hidden master server (which provides the raw zone data) and a set of publicly accessible slave servers (which only serve the signed data). [RT #26224/23657] - "rndc flushtree " command removes the specified name and all names under it from the cache. [RT #19970] - "rndc sync" command dumps pending changes in a dynamic zone to disk without a freeze/thaw cycle. "rndc sync -clean" removes the journal file after syncing. "rndc freeze" no longer removes journal files. [RT #22473] - The new "rndc signing" command provides greater visibility and control of the automatic DNSSEC signing process. Options to this new command include "-list " which will show the current state of signing operations overall or per specified zone. [RT #23729] - The "also-notify" option now takes the same syntax as "masters", thus it can use named master lists and TSIG keys. [RT #23508] - "auto-dnssec" zones can now have NSEC3 parameters set prior to signing. [RT #23684] - The "dnssec-signzone -D" option causes dnssec-signzone to write DNSSEC data to a separate output file. This allows you to put "$INCLUDE example.com.signed" into the zonefile for example.com, run "dnssec-signzone -SD example.com", and the result is a fully signed zone which did *not* overwrite your original zone file. Running the same command again will incrementally re-sign the zone, replacing only those signatures that need updating, rather than signing the entire
certain records not being returned from cache?
Greetings and thanks for any help - I'm running into what seems like a strange problem. On our bind (9.7.3-P3-RedHat-9.7.3-2.el6_1.P3.3, but patched to latest), we seem to be having some domains [we aren't auth for] that aren't returning expected information from cache (although thousand of other domains resolve just fine). Digs on/from other providers (with other recursing servers outside our networks) seem to work correctly. To me, it seems like all information at least to the gTLD (and the ns of the domain?) is correct. So the problem seems to be us, but I'm not sure why. It seems that bind has the correct info in it's cache db (see below), and yet it will not return the data. Details below, happy to provide more upon request! An example is carsoncityschools.com. A dig +trace from two of our (different) networks works fine until after retrieving NS records: carsoncityschools.com. 172800 IN NS ns1.carsoncityschools.com. carsoncityschools.com. 172800 IN NS ns2.carsoncityschools.com. That's fine. But then [a packet sniff reveals that] the local resolver hits our server to look up (e.g.) ns1.carsoncityschools.com, and our servers (all) respond back with SERVFAIL. A dig @GTLD (any) of ns1 returns correct results with glue, and a dig, from one of our name servers directly to @50.23.15.156, return correct results: ;; QUESTION SECTION: ;ns1.carsoncityschools.com. IN A ;; AUTHORITY SECTION: carsoncityschools.com. 172800 IN NS ns1.carsoncityschools.com. carsoncityschools.com. 172800 IN NS ns2.carsoncityschools.com. ;; ADDITIONAL SECTION: ns1.carsoncityschools.com. 172800 INA 50.23.15.156 ns2.carsoncityschools.com. 172800 INA 50.23.28.180 However, a dig direct to @OURDNS (tried three distinct systems/networks) for, e.g. ns1.carsoncityschools.com, yields poor results: ; <<>> DiG 9.7.3-P3-RedHat-9.7.3-2.el6_1.P3.3 <<>> @OURDNS ns1.carsoncityschools.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32117 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns1.carsoncityschools.com. IN A So, if I'm on the right track here, it seems like perhaps our server is not caching the information or retrieving the info, because everything else seems fine. A restart of named does not fix the problem. I then ran a rndc dumpdb, and looked at the file (after attempting a dig again). The (internal cache db) dumpdb yields this: carsoncityschools.com. 172791 NS ns1.carsoncityschools.com. 172791 NS ns2.carsoncityschools.com. ; glue ns1.carsoncityschools.com. 172791 A 50.23.15.156 ; glue ns2.carsoncityschools.com. 172791 A 50.23.28.180 and in the ; ns2.carsoncityschools.com [v4 TTL 1] [v4 success] [v6 unexpected] ; 50.23.28.180 [srtt 1] [flags ] ; ns1.carsoncityschools.com [v4 TTL 1] [v4 success] [v6 unexpected] ; 50.23.15.156 [srtt 14] [flags ] Not knowing the db structure in detail, I can't be sure, but doesn't it look like the cache has correct data in it. If that's the case, why does a local dig @OURDNS return a value? Does anyone have other suggestions to try? THANK YOU! -- cheers and thanks, Ian Veach, Systems Analyst System Computing Services, Nevada System of Higher Education ___ 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: RFC 6303 vs. BIND: NS ... has no address records (A or AAAA)
On 01/09/2012 14:13, Irwin Tillman wrote: > RFC 6303 says that a recursive nameserver should locally serve > a number of DNS zones. Section 3 provides this generic empty > zone for this purpose, in master file format: > > @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800 > @ 10800 IN NS @ > What's the recommended approach? I installed the following as the default-empty zone file for FreeBSD back in 2007, and it has withstood numerous versions of BIND in the process: $TTL 3h @ SOA @ nobody.localhost. 42 1d 12h 1w 3h ; Serial, Refresh, Retry, Expire, Neg. cache TTL @ NS @ ; Silence a BIND warning @ A 127.0.0.1 You might find the various files at http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/namedb/ interesting as well. hth, Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
RFC 6303 vs. BIND: NS ... has no address records (A or AAAA)
RFC 6303 says that a recursive nameserver should locally serve
a number of DNS zones. Section 3 provides this generic empty
zone for this purpose, in master file format:
@ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
@ 10800 IN NS @
The RFC notes:
"The NS RR is needed as some UPDATE [RFC2136] clients use NS queries
to discover the zone to be updated. Having no address records for
the nameserver is expected to abort UPDATE processing in the client."
Ignoring BIND's support for automatic empty zones for selected zones
for the moment, if try to load a zone in BIND using that zone file above:
zone "255.255.255.255.in-addr.arpa" in {
type master;
file "empty-inaddr-zone";
};
BIND 9.8.1-P1 rightly complains:
general: error: zone 255.255.255.255.in-addr.arpa/IN: NS
'255.255.255.255.in-addr.arpa' has no address records (A or )
general: error: zone 255.255.255.255.in-addr.arpa/IN: not loaded due to errors.
Omitting the NS record from the zone file would allow the zone file
to load, but cause lookups to return SERVFAIL; that's not what we want.
--
Prior to RFC 6303, I'd instead use a zone file such as:
@ 10800 IN SOA @
bogus-mname-to-suppress-dynamic-updates.real-mname-is.myhost.example.com. 1
3600 1200 604800 10800
10800 IN NS myhost.example.com.
where "myhost.example.com." was replaced with a canonical name of "this"
nameserver.
I'd ensure that myhost.example.com has an A-record
and that
bogus-mname-to-suppress-dynamic-updates.real-mname-is.myhost.example.com would
not have an A-record.
--
What's the recommended approach?
___
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: Exercising RFC 5011 rollovers
Back in November, I started a thread about testing BIND's managed-keys code for tracking trust anchor rollovers. Since then I have been doing some experiments which, as pointed out then, can take quite some time due to the 30-day "hold-down" times specified in RFC 5011. Recently I thought I had discovered my first bug in this area, but I have since downgraded it to an infelicity, and maybe even that is putting it too strongly. I wonder what others think. If a new DNSKEY-with-SEP record is published, and fairly soon after removed (without ever appearing as revoked), RFC 5011 specifies | If the resolver ever sees the DNSKEY RRSet without the new key but | validly signed, it stops the acceptance process for that key and | resets the acceptance timer. What BIND does is to retain the entry for the new key in managed-keys.bind but every time it notices that it is no longer published it sets the KEYDATA.addhd field 30 days in the future. Thus it will never get accepted as a trust anchor. That seems to satisfy the letter of the law, but it does mean that managed-keys.bind remains cluttered with such keys. Would it not be better for it simply to drop the entry whenever is sees a (properly signed) DNSKEY RRSet without the key, if the KEYDATA.addhd time has not yet been reached? If the key subsequently re-appeared, it would get added again, with the 30-day hold-down period started again, which seems equally compatible with RFC 5011. I might add that I hadn't really meant to perform this experiment at this time... it happened as a result of specifying a set of key publication and activation times in January 2011 when January 2012 was intended :-) -- Chris Thompson Email: c...@cam.ac.uk ___ 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: NAPTR Catch-all
> 7.7.7.5.2.1.4.4.9.9.8.1.2.INNAPTR10010"u" "E2U+sip" > "!(^.*$)!sip:2799820784000132" .; Testing This isn't a wildcard, so it will not match as a wildcard. Can you provide a few example RRs which you want to synthesize using wildcards? It's not clear (to me at least) what you're trying to do. There is a good chance that you have to change the regexp part of the NAPTR record. ___ 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: forwarding "@" to a different domain?
On Mon, 9 Jan 2012 15:11:19 + "Lightner, Jeff" wrote Just as a follow on to that prior thread. I was able to setup the CNAME for www and * at the Registrar without A records as indicated. Unfortunately the * at registrar equated to "*." Meaning for example ftp.mydomain.com would work with that CNAME but the domain itself, mydomain.com, would not. Despite the ecommerce vendor (Amazon ultimately) saying one should NOT setup A records their response to us was to leave the two CNAMES (www and *) in place and setup an 3 A records for the domain itself. Thanks Jeff: I ended up setting up a website with a permanent redirect on my webserver server to the shopify server...hopefully that will work. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of /dev/rob0 Sent: Sunday, January 08, 2012 6:33 PM To: bind-users@lists.isc.org Subject: Re: forwarding "@" to a different domain? On Sunday 08 January 2012 09:48:42 enigmedia wrote: > Hi All: I have a situation where I need to forward requests for > "mydomain.com" and "www.mydomain.com" to a third party: "mydomain.com" is a real domain, and probably not yours. If for some reason you do not want to mention your real domain name, use "example.com" (or example.TLD for most top-level domains), which is reserved for examples. > "mydomain.myshopify.com" (while still pointing other things like > MX records elsewhere). > > I realize I can point a CNAME for "WWW" to > "mydomain.myshopify.com", but how do I point "mydomain.com" to > this third party if there is no A record to point to? This is beginning to be a FAQ here, perhaps due to the popularity of such hosting services (which seem to have been designed by people who have a poor understanding of DNS.) This was my reply in a thread last month; refer to the entire thread for more: https://lists.isc.org/pipermail/bind-users/2011-December/085918.html -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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 Athena(r), Created for the Cause(tm) Making a Difference in the Fight Against Breast Cancer - CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank 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 ___ 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: forwarding "@" to a different domain?
Just as a follow on to that prior thread. I was able to setup the CNAME for www and * at the Registrar without A records as indicated. Unfortunately the * at registrar equated to "*." Meaning for example ftp.mydomain.com would work with that CNAME but the domain itself, mydomain.com, would not. Despite the ecommerce vendor (Amazon ultimately) saying one should NOT setup A records their response to us was to leave the two CNAMES (www and *) in place and setup an 3 A records for the domain itself. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of /dev/rob0 Sent: Sunday, January 08, 2012 6:33 PM To: bind-users@lists.isc.org Subject: Re: forwarding "@" to a different domain? On Sunday 08 January 2012 09:48:42 enigmedia wrote: > Hi All: I have a situation where I need to forward requests for > "mydomain.com" and "www.mydomain.com" to a third party: "mydomain.com" is a real domain, and probably not yours. If for some reason you do not want to mention your real domain name, use "example.com" (or example.TLD for most top-level domains), which is reserved for examples. > "mydomain.myshopify.com" (while still pointing other things like > MX records elsewhere). > > I realize I can point a CNAME for "WWW" to > "mydomain.myshopify.com", but how do I point "mydomain.com" to > this third party if there is no A record to point to? This is beginning to be a FAQ here, perhaps due to the popularity of such hosting services (which seem to have been designed by people who have a poor understanding of DNS.) This was my reply in a thread last month; refer to the entire thread for more: https://lists.isc.org/pipermail/bind-users/2011-December/085918.html -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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 Athena(r), Created for the Cause(tm) Making a Difference in the Fight Against Breast Cancer - CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank 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
NAPTR Catch-all
Hi Everyone. I've been trying to get a solution working where by I need to supply a response based on a NAPTR query. The problem is, the domain section of the NAPTR needs to be "dynamic", as this could be different per query. I based my config on the following url, and all works well for A record lookups, however NAPTR lookups fail: http://doc.pfsense.org/index.php/Creating_a_DNS_Black_Hole_for_Captive_Portal_Clients Below is my config: ; ; BIND reverse data file for local loopback interface ; $TTL604800 @INSOA. root.localhost. ( 201201051527 ; Serial 604800; Refresh 86400; Retry 2419200; Expire 604800 ); Negative Cache TTL ; @INNS. .INA99.99.99.5 *.INA99.99.99.5 7.7.7.5.2.1.4.4.9.9.8.1.2.INNAPTR10010"u" "E2U+sip""!(^.*$)!sip:2799820784000132" .; Testing If i do the query for 7.7.7.5.2.1.4.4.9.9.8.1.2. - I get the correct response, however, if I add onto the query as such: 7.7.7.5.2.1.4.4.9.9.8.1.2.microsoft.com I get the following response: ; <<>> DiG 9.7.0-P1 <<>> 7.7.7.5.2.1.4.4.9.9.8.1.2.microsoft.com @127.0.0.1 -t NAPTR ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21413 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;7.7.7.5.2.1.4.4.9.9.8.1.2.microsoft.com. IN NAPTR ;; AUTHORITY SECTION: .604800INSOA. root.localhost. 3632555911 604800 86400 2419200 604800 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jan 9 14:36:50 2012 ;; MSG SIZE rcvd: 105 I checked a few items on the web, but could not find out if what I'm doing was impossible. Your valued input would be greatly appreciated. Many thanks 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
Re: ddns and views
On 01/09/2012 07:42 AM, Psychobyte wrote: Sorry, I didn't mean rndc I meant DDNS updates. in particular using the Perl Net::DNS module. DDNS works the same way as every other DNS packet with views; the "view" "match" statement determines which view you are talking to. The match statement can match a client TSIG key. Therefore, if you use TSIG with your DDNS, you can use two keys - one for view A, one for view B. Usual disclaimer: views are complicated, don't use them if you have to, yada yada. There are examples of using TSIG and views in the list archives. ___ 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
