I have domain example.net in production, and have recently acquired example.us and example.info.
For whatever reason, I want example.us to simply mirror example.net, which is dynamically udpdated (and dnssec). And I want example.us to be zero maintenance. (Well, OK I know I need separate DNSSEC keys, but I don't want to mirror every update made in .net to .us) So, I add a zone to ns1.example.net that looks like: (In view "internal") zone "example.us" { auto-dnssec maintain; type master; allow-transfer { key "TSIG_GLOBAL_KEY"; }; file "EXAMPLE_US.DB"; update-policy { grant "TSIG_GLOBAL_KEY" subdomain example.us. ANY ; }; }; $ORIGIN . $TTL 600 ; 10 minutes example.us. IN SOA ns1.example.net. examplenetadmin.example.net. ( 2011063001 ; serial 172800 ; refresh (2 days) 600 ; retry (10 minutes) 2419200 ; expire (4 weeks) 600 ; minimum (10 minutes) ) example.us. IN DNAME example.net. example.us. IN NS ns1.example.net. example.us. IN NS ns2.example.net. I get SERVFAIL with dig if I ask about, say www.example.us @ns1.example.net (www.example.net does exist). I see nothing in the named.log, except the trace 99 /notrace commands bracketing the dig, and if I turn on querylog: client <ns1 IP>#33256: view internal: query: www.example.us IN A + (<ns1 IP>). If I look at the named statistics channel, I see that example.us is being served, but the zone serial is '-', not '2011063001'. Questions: o Am I confused about DNAME placement - would it have to go in .US? If so, is this possible? (I don't mean technically possible - I mean practically - e.g. thru a registrar such as godaddy, enom, etc). If not, what explains the SERVFAIL? o Why is '-' reported for the zone serial? o I understand that DNAME and MX don't play well together (DNAME is essentially CNAME, and MX doesn't allow CNAMEs). I suspect I'd have to live with that - unless there are wiser heads? o Is there a better approach? (Assume that I'll also want to do the same thing to example.info...) Thanks. --------------------------------------------------------- This communication may not represent my employer's views, if any, on the matters discussed. _______________________________________________ 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