Re: Wildcard CNAME record?
On 16.01.13 14:57, Baird, Josh wrote: Is it acceptable to have a wildcard CNAME? Example: * IN CNAMEsomewhere.com. Or, would it be advised to only use wildcard 'A' records? while it is technically valid, I don't think it's acceptable to use solutions that require wildcards ;-) -- 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. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 ___ 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: Wildcard CNAME record?
Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 16.01.13 14:57, Baird, Josh wrote: Is it acceptable to have a wildcard CNAME? Example: * IN CNAMEsomewhere.com. Or, would it be advised to only use wildcard 'A' records? while it is technically valid, I don't think it's acceptable to use solutions that require wildcards ;-) RFC 4592 is enlightening in a rather unpleasant manner. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Wildcard CNAME record?
In article mailman.1072.1358349671.11945.bind-us...@lists.isc.org, Oliver Peter li...@peter.de.com wrote: On Wed, Jan 16, 2013 at 02:57:48PM +, Baird, Josh wrote: Is it acceptable to have a wildcard CNAME? Example: * IN CNAMEsomewhere.com. Or, would it be advised to only use wildcard 'A' records? Not valid since there should be SOA and NS records for somewhere.com, the CNAME would conflict with them. But wildcards only synthesize records that are actually queried for. If no one ever asks for these SOA and NS records, the conflicts will never occur. They're the DNS equivalent of trees falling in a forest. -- 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: Wildcard CNAME record?
On Wed, Jan 16, 2013 at 10:33:03AM -0500, Barry Margolin wrote: In article mailman.1072.1358349671.11945.bind-us...@lists.isc.org, Oliver Peter li...@peter.de.com wrote: On Wed, Jan 16, 2013 at 02:57:48PM +, Baird, Josh wrote: Is it acceptable to have a wildcard CNAME? Example: * IN CNAMEsomewhere.com. Or, would it be advised to only use wildcard 'A' records? Not valid since there should be SOA and NS records for somewhere.com, the CNAME would conflict with them. But wildcards only synthesize records that are actually queried for. If no one ever asks for these SOA and NS records, the conflicts will never occur. They're the DNS equivalent of trees falling in a forest. Gah, mixed it up, was thinking the other way round. Sorry. -- Oliver PETER oli...@opdns.de 0x456D688F You need healthy, natural sleep. Chew some Valerian root and get more exercise. signature.asc Description: 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: Wildcard CNAME record?
Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 16.01.13 14:57, Baird, Josh wrote: Is it acceptable to have a wildcard CNAME? Example: * IN CNAMEsomewhere.com. Or, would it be advised to only use wildcard 'A' records? while it is technically valid, I don't think it's acceptable to use solutions that require wildcards ;-) On 16.01.13 15:16, Tony Finch wrote: RFC 4592 is enlightening in a rather unpleasant manner. yes, very unpleasant. I read that more than once and was repeatedly not able to fully understand it. -- 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. I don't have lysdexia. The Dog wouldn't allow that. ___ 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
MNAME not a listed NS record
Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record? The server listed as MNAME will host the zone and is authoritative for the zone, but out of latency concerns it isn't ideal to have other resolvers querying this server. Various online DNS diagnostic tools throw warnings, but as far as I can tell from the RFCs, this is a valid configuration. Is it valid? Are there any operational gotchas to be aware of or can I ignore the warnings? -- 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: MNAME not a listed NS record
On Jan 16, 2013, at 12:40 PM, Dave Warren wrote: Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record? Sure. The SOA MNAME is expected to be the primary master nameserver for the zone; it's where things like dhcpd and such send dynamic updates for the zone to. The server listed as MNAME will host the zone and is authoritative for the zone, but out of latency concerns it isn't ideal to have other resolvers querying this server. Okay...so why would you use that nameserver at all, then? Choose a nameserver which is suitable for other resolvers to query for your master. Various online DNS diagnostic tools throw warnings, but as far as I can tell from the RFCs, this is a valid configuration. Is it valid? Are there any operational gotchas to be aware of or can I ignore the warnings? It's not valid, but if you aren't doing dynamic updates to the zone, and you can live without SOA serial # sanity checking by slave nameservers trying to determine whether the zone has been updated or not by checking with the MNAME server, sure, you can setup DNS in such a fashion and (probably) nothing else would break. Regards, -- -Chuck ___ 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: MNAME not a listed NS record
There is no issue with a configuration like this. It is the very definition of a stealth master and is a very common configuration. Any DDNS updates will continue to reach the stealth master via the mname and no resolvers will find the master via NS records so it won't be queried. On Jan 16, 2013 3:42 PM, Dave Warren li...@hireahit.com wrote: Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record? The server listed as MNAME will host the zone and is authoritative for the zone, but out of latency concerns it isn't ideal to have other resolvers querying this server. Various online DNS diagnostic tools throw warnings, but as far as I can tell from the RFCs, this is a valid configuration. Is it valid? Are there any operational gotchas to be aware of or can I ignore the warnings? -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/**davejwarrenhttp://ca.linkedin.com/in/davejwarren __**_ Please visit https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-usersto unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/**listinfo/bind-usershttps://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: MNAME not a listed NS record
In article mailman.1077.1358370123.11945.bind-us...@lists.isc.org, Chuck Swiger cswi...@mac.com wrote: On Jan 16, 2013, at 12:40 PM, Dave Warren wrote: Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record? Sure. The SOA MNAME is expected to be the primary master nameserver for the zone; it's where things like dhcpd and such send dynamic updates for the zone to. But that doesn't mean it should be the server for resolver queries. The server listed as MNAME will host the zone and is authoritative for the zone, but out of latency concerns it isn't ideal to have other resolvers querying this server. Okay...so why would you use that nameserver at all, then? Choose a nameserver which is suitable for other resolvers to query for your master. The master could be behind a firewall that only allows the published nameservers to connect to it. The performance requirements of a nameserver that serves public queries are different from a server that only has to respond to zone transfer requests from the published nameservers. Various online DNS diagnostic tools throw warnings, but as far as I can tell from the RFCs, this is a valid configuration. Is it valid? Are there any operational gotchas to be aware of or can I ignore the warnings? Consider this a sanity check, in case you intended to list one of the NS records but made a typo, not a validity check. -- 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: MNAME not a listed NS record
On Jan 16, 2013, at 1:42 PM, Barry Margolin wrote: In article mailman.1077.1358370123.11945.bind-us...@lists.isc.org, Chuck Swiger cswi...@mac.com wrote: On Jan 16, 2013, at 12:40 PM, Dave Warren wrote: Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record? Sure. The SOA MNAME is expected to be the primary master nameserver for the zone; it's where things like dhcpd and such send dynamic updates for the zone to. But that doesn't mean it should be the server for resolver queries. True, but I don't see much utility from a nameserver which can be dynamically updated but not queried. The server listed as MNAME will host the zone and is authoritative for the zone, but out of latency concerns it isn't ideal to have other resolvers querying this server. Okay...so why would you use that nameserver at all, then? Choose a nameserver which is suitable for other resolvers to query for your master. The master could be behind a firewall that only allows the published nameservers to connect to it. Sure. In which case, why publish an internal-only machine into the public DNS via your SOA record? Someone else made mention of a stealth master, but my definition of that is an internal machine which is not visible in any publicly published records. The performance requirements of a nameserver that serves public queries are different from a server that only has to respond to zone transfer requests from the published nameservers. True. Handling AFXRs isn't much work, and you can always revert to other methods of replicating zone data if need be, so my primary concern is making nameservers work well enough to handle the query load, and not to make nameservers just handle zone transfers. Regards, -- -Chuck ___ 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 DS vs DNSKEY record publication order question (wrt key algorithm rollover)
Brian Paul Kroth bpkr...@gmail.com 2013-01-15 23:19: Hello All, First, I'm not currently on the list, so please CC if me if you could. Let's try this again now that I'm on the list. Next, I've been working on some scripts to get KSK rotation semi-automated or at least alerting in our environment and I've got some questions about the DS record requirements and their relation to the files generated and included by dnssec-signzone's smart signing feature. RFC 4035 sec 2.2 says There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). This says to me that you can have extra DNSKEY records (that don't yet have a corresponding DS pair upstream), but not extra DS records (that don't yet have a corresponding DNSKEY downstream), since every DS records must have a key and sig associated with it. RFC 4035 sec 2.4 says A DS RR SHOULD point to a DNSKEY RR that is present in the child's apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed by the corresponding private key. DS RRs that fail to meet these conditions are not useful for validation, but because the DS RR and its corresponding DNSKEY RR are in different zones, and because the DNS is only loosely consistent, temporary mismatches can occur. This says to me that the RFC also acknowledges that things might/will get out of sync due to caching in DNS, but doesn't describe to me what resolvers do in that context. Do they complain that the DS they happened to choose to look for a valid chain of trust didn't work and throw the whole thing out, or do they just move along to the next one in the hopes that it might succeed? RFC 5011 sec 6.6 says 1. Generate a new DNSKEY and DS record and provide the DS record to the parent along with DS records for the old keys. 2. Once the parent has published the DSs, add the new DNSKEY to the RRSet and revoke ALL of the old keys at the same time, while signing the DNSKEY RRSet with all of the old and new keys. 3. After 30 days, stop publishing the old, revoked keys and remove any corresponding DS records in the parent. This says to me that DS records SHOULD be published before the DNSKEY is, which seems to contradict the first quote. To add some more confusion, RFC 4641 (now 6781) sec 4.2.4 also mentions standby keys and pushing DS records without DNSKEY records for KSK keys. The way to deal with stand-by keys differs for ZSKs and KSKs. To make a stand-by ZSK, you need to publish its DNSKEY RR. To make a stand-by KSK, you need to get its DS RR published at the parent. Why to the bind-users list you ask? Well, I'm trying to figure out if the dsset-* files generated by the smart signing feature of dnssec-signzone -S are smart enough to be usable for key rotation inclusion and warning scripts, or if I need to come up with that logic on my own and generate and include DS records separately from the -g option. I think it gets particularly tricky when you start considering things like key algorithm rollover where one needs to (I think) first yank the DS records, wait, then revoke the old algorithm keys, wait, then yank the keys (mostly due to the first quote I posted). If the parent and child are on the same server and being resigned during that waiting period, then dnssec-signzone will continue to overwrite and include the olds keys in the dsset-* files, and the -g option would normally just include them in the parent. Unless I've misinterpreted something above, the only way around that that I see is to maintain your own DS records in the parent zones (whether they're local or remote), including them manually (ie: via perl/db :), and specifically *not* using the -g option (which makes me sad). Anyways, thoughts, opinions, advice? Given the latest RFC evidence I posted, I think my summary view is as follows, please correct me if it seems wrong: 1) DS records are just used to validate the chain of trust upstream for DNSKEY records found downstream, so there MUST exist a DS record for each DNSKEY/RRSIG chain you intend to have used for validating RRSIGs (though not for just standby keys that are listed in DNSKEY records but not signing), but there need not exist a DNSKEY/RRSIG chain for each DS record (which is what contradicts 4035 2.2). So, we could prepublish DS records without an issue, but DNSKEYs that are published must be validated by an existing chain of trust (DNSKEY/DS pair) before they can be used to validate other RRSIGs. 2) dnssec-signzone probably generates the right dsset-* files (Does the Right Thing TM) and can be included without much thought. 3) With the above, in an algorithm rollover, I should be able to do something like this: - Generate keys with a new algorithm and publish them, but don't activate them yet. #
Re: MNAME not a listed NS record
From: Dave Warren li...@hireahit.com Various online DNS diagnostic tools throw warnings, Speaking of so called DNS diagnostic tools, one claims that my domains have DNS servers with private network addresses. My only guess is that they don't know the difference between IPv6 addresses and RFC 1918 addresses. On the other hand, maybe that was random FUD intended to drum up business, because they've stopped that nonsense in the last 3 days and without my changing anything. Another tool claims that ns3.isc-sns.info is not sending glue for one of my domains. That one is among the several that claim that having a single MX record is a defect instead of a feature in this century. (On today's Internet, where all SMTP clients from which you might want to receive mail can reach all of your SMTP servers at almost any time and do proper queuing for during very rare exceptions, one needs only one MX RR. Unless you want to load balance millions of messages per day among SMTP servers on multiple networks, you want a single a MX RR to avoid spam backscatter without having to synchronize your definition of valid mailbox at the distributed SMPT servers needed in the multiple-MX wisdom of the previous centurywell, there is the exception of bogus MX RRs for trapping spam.) Then there is the supposed dire insecurity of answering `dig ch version.bind txt` Let's not forget the popular DNS checkers that claim my SMTP servers are open relays. Don't ask me about technical connections to DNS health in seeing whether an SMTP Rcpt_To command is answered with 250_Ok. The spammers who continually hit my SMTP servers with floods of checks of common holes in relay authentication and authorization evidently know that 250_Ok even at the end of a DATA command doesn't indicate that an SMTP server has relayed anything. There is a common thread among the bogus DNS health checks from outfits in the DNS help business and the worst domain registrars. Their sales stories are based on the notion that DNS, HTTP, SMTP, and the Internet in general are too complicated, dangerous, and generally scary for mere humans to handle, and so you'd better buy their patent medicine. On the other hand, good outfits simply sell competent services, perhaps including technical support, but always without acting like proverbial used car and computer saleslime. Vernon Schryverv...@rhyolite.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
Re: MNAME not a listed NS record
-Original Message- From: Vernon Schryver v...@rhyolite.com Date: Wednesday, January 16, 2013 5:05 PM To: bind-users@lists.isc.org bind-users@lists.isc.org Subject: Re: MNAME not a listed NS record From: Dave Warren li...@hireahit.com Various online DNS diagnostic tools throw warnings, Speaking of so called DNS diagnostic tools, one claims that my domains have DNS servers with private network addresses. My only guess is that they don't know the difference between IPv6 addresses and RFC 1918 addresses. On the other hand, maybe that was random FUD intended to drum up business, because they've stopped that nonsense in the last 3 days and without my changing anything. Same thing here. It's important to remember these tools are written by humans that also have busy mornings where they don't get to drink enough coffee... :-) Awhile back we updated an internal tool that generates DNS records as part of a hosted email solution and one of these tools started baulking. Everything we were doing was RFC compliant, but the tool turned red. This spawned a lot of calls to support from customers who took the tool as an omniscient being, support escalated to management because the customer is always right (and were threatening to go elsewhere even after being pointed to relevant RFCs and walking through dig showing everything worked just fine in practice). After triple-checking the RFCs and contacting the maintainer with our justification, the tool started doing the right thing a few weeks later. So now we need tools that check the tools, and they need to be written by omniscient beings... Failing that, the big thing I hope folks learn from this is that automated tools written by third parties are helpful at times, but no substitute for familiarity with standards and generally understanding how things work. ___ 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: MNAME not a listed NS record
In article mailman.1080.1358373225.11945.bind-us...@lists.isc.org, Chuck Swiger cswi...@mac.com wrote: On Jan 16, 2013, at 1:42 PM, Barry Margolin wrote: In article mailman.1077.1358370123.11945.bind-us...@lists.isc.org, Chuck Swiger cswi...@mac.com wrote: On Jan 16, 2013, at 12:40 PM, Dave Warren wrote: Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record? Sure. The SOA MNAME is expected to be the primary master nameserver for the zone; it's where things like dhcpd and such send dynamic updates for the zone to. But that doesn't mean it should be the server for resolver queries. True, but I don't see much utility from a nameserver which can be dynamically updated but not queried. Who says you're using dynamic update? The MNAME field has been part of the DNS standard since long before DHCP and dynamic update. In many instances it's just an FYI field. The server listed as MNAME will host the zone and is authoritative for the zone, but out of latency concerns it isn't ideal to have other resolvers querying this server. Okay...so why would you use that nameserver at all, then? Choose a nameserver which is suitable for other resolvers to query for your master. The master could be behind a firewall that only allows the published nameservers to connect to it. Sure. In which case, why publish an internal-only machine into the public DNS via your SOA record? Someone else made mention of a stealth master, but my definition of that is an internal machine which is not visible in any publicly published records. You have to put something in the MNAME. You could lie and put one of the public nameservers, but why do that when you could put the true master? The performance requirements of a nameserver that serves public queries are different from a server that only has to respond to zone transfer requests from the published nameservers. True. Handling AFXRs isn't much work, and you can always revert to other methods of replicating zone data if need be, so my primary concern is making nameservers work well enough to handle the query load, and not to make nameservers just handle zone transfers. Do that on the public nameservers. The hidden master doesn't need to be dedicated to nameserving, since it's not handling all the load that the public servers do. -- 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: MNAME not a listed NS record
On Jan 16, 2013, at 4:30 PM, Barry Margolin wrote: [ ... ] On Jan 16, 2013, at 12:40 PM, Dave Warren wrote: Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record? Sure. The SOA MNAME is expected to be the primary master nameserver for the zone; it's where things like dhcpd and such send dynamic updates for the zone to. But that doesn't mean it should be the server for resolver queries. True, but I don't see much utility from a nameserver which can be dynamically updated but not queried. Who says you're using dynamic update? The MNAME field has been part of the DNS standard since long before DHCP and dynamic update. In many instances it's just an FYI field. Nothing says one is using dynamic updates; if you aren't, then sure, the MNAME field is quite a bit less important than if you are. [ ... ] Sure. In which case, why publish an internal-only machine into the public DNS via your SOA record? Someone else made mention of a stealth master, but my definition of that is an internal machine which is not visible in any publicly published records. You have to put something in the MNAME. You could lie and put one of the public nameservers, but why do that when you could put the true master? Are you asking why someone would not publish an internal-only hostname? Maybe it's using RFC-1918 addresses and only reachable on one's LAN? The performance requirements of a nameserver that serves public queries are different from a server that only has to respond to zone transfer requests from the published nameservers. True. Handling AFXRs isn't much work, and you can always revert to other methods of replicating zone data if need be, so my primary concern is making nameservers work well enough to handle the query load, and not to make nameservers just handle zone transfers. Do that on the public nameservers. The hidden master doesn't need to be dedicated to nameserving, since it's not handling all the load that the public servers do. Sure. The thing is, by the time an organization grows big enough to maintain dedicated internal and external DNS views, and loads their DNS servers to the point where dedicating a server just to act as master for zone data rather than handling queries makes sense, well, you also tend to end up with firewalls, load-balancers, and such which can redirect traffic based on source address, server load and aliveness, etc. You publish VIPs which handle your DNS traffic, and then balance that internally onto your pool of reals (the DNS server boxes) as you choose. Keeping query load low or moving it entirely off of a particular box is a LB config change. YMMV Regards, -- -Chuck ___ 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: MNAME not a listed NS record
In article mailman.1085.1358384707.11945.bind-us...@lists.isc.org, Chuck Swiger cswi...@mac.com wrote: On Jan 16, 2013, at 4:30 PM, Barry Margolin wrote: [ ... ] On Jan 16, 2013, at 12:40 PM, Dave Warren wrote: Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record? Sure. The SOA MNAME is expected to be the primary master nameserver for the zone; it's where things like dhcpd and such send dynamic updates for the zone to. But that doesn't mean it should be the server for resolver queries. True, but I don't see much utility from a nameserver which can be dynamically updated but not queried. Who says you're using dynamic update? The MNAME field has been part of the DNS standard since long before DHCP and dynamic update. In many instances it's just an FYI field. Nothing says one is using dynamic updates; if you aren't, then sure, the MNAME field is quite a bit less important than if you are. You seemed to be assuming that they are, and that the MNAME field is important. [ ... ] Sure. In which case, why publish an internal-only machine into the public DNS via your SOA record? Someone else made mention of a stealth master, but my definition of that is an internal machine which is not visible in any publicly published records. You have to put something in the MNAME. You could lie and put one of the public nameservers, but why do that when you could put the true master? Are you asking why someone would not publish an internal-only hostname? Maybe it's using RFC-1918 addresses and only reachable on one's LAN? No, I'm asking why you would put one of the external nameservers in the MNAME field, even if it's not really the master, just to avoid the warning that the MNAME isn't one of the NS. But the rest of your answers seem to be just saying that there's no point in having a hidden master in the first place. -- 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: MNAME not a listed NS record
Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record? Not at all; that works fine. The server listed as MNAME will host the zone and is authoritative for the zone, but out of latency concerns it isn't ideal to have other resolvers querying this server. Just omit the server listed as MNAME from the NS RRset. Various online DNS diagnostic tools throw warnings, but as far as I can tell from the RFCs, this is a valid configuration. Is it valid? Yes, it is valid. (And most of the online diagnostic tools I know suck: for example, they complain about SOA serial numbers not being in MMDDn format.) Are there any operational gotchas to be aware of or can I ignore the warnings? You should be aware of DNS Updates which will, by default, be directed at the server listed in SOA MNAME. If you don't do DHCP, say, then it's fine to ignore that. -JP ___ 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: MNAME not a listed NS record
On 1/16/2013 22:17, Jan-Piet Mens wrote: Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record? Not at all; that works fine. Thanks. That's what I thought, but I wanted to confirm that this particular warning didn't have any backing in reality. Are there any operational gotchas to be aware of or can I ignore the warnings? You should be aware of DNS Updates which will, by default, be directed at the server listed in SOA MNAME. If you don't do DHCP, say, then it's fine to ignore that. At this point I don't do any dynamic DNS through BIND at all right now, the only dynamic zones we currently host are internal-only on Microsoft DNS and update via AD, so I think we'll be safe in this regard. Thanks! -- 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: MNAME not a listed NS record
On 1/16/2013 13:53, Chuck Swiger wrote: True, but I don't see much utility from a nameserver which can be dynamically updated but not queried. It *can* be queried, it's just not ideal as the machine has a fair amount of load and has fairly high latency. Since I have secondaries in colocation facilities with available resources, it makes more sense for them to handle external queries. I'm also not sure where you're getting dynamic updates from, but we don't do any dynamic updates through BIND at this time. Sure. In which case, why publish an internal-only machine into the public DNS via your SOA record? Because it is actually the master, and from what I can tell, the slaves will check against the MNAME to confirm whether they're up to date or not. (Yes, notifies will usually take care of this. Usually.) Someone else made mention of a stealth master, but my definition of that is an internal machine which is not visible in any publicly published records. Strictly speaking, it's not internal-only, it's just on a slower, occasionally overloaded connection which will result in some percentage of requests taking significantly longer to answer. It's also on a somewhat overloaded server, so it just makes more sense to push external traffic to more ideal services. -- 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
