Re: [Dnsmasq-discuss] Feature Request(s)
On 15/03/12 22:22, Rob Zwissler wrote: Consistency is always nice, so the choice is between consistent behavior across hosts dnsmasq.conf style configs, or consistent behavior within dnsmasq.conf, I'd vote for the latter, so expand-hosts would be ignored for host-record. Agreed If it does expand it it for host-record but not txt-record, etc, that seems somewhat un-intuitive. Perhaps a second expand-host-record to separately enable that? Or a more general expand-records (?) directive that would work for host-record, txt-record, etc... Hmm, maybe. I have a feeling that this is getting complex, especially as the domain added depends on --domain, which can be address-dependent. expand-hosts for /etc/hosts has the justification that (some) OS's work that way when using /etc/hosts outside dnsmasq, for dnsmasq-exclusive config, I'm inclined to keep it simple, especially as it's possible to include a simple name and an expanded name in the same line host-record=laptop, laptop.thekelleys.org.uk, 192.168.0.1 The bind behavior with default expansion and a . to override seems nice, simple intuitive, what about a expand-bind-style directive to turn that behavior on, so as not to break existing syntax, but give that fine grained control to people who want it? That breaks the rule that syntactically different configurations should vary by more than one pixel ;-). Missing the period at the end of a name in a BIND file is almost as annoying as mixing spaces and tabs in a Makefile. I've got the host-record syntax above working fine. I'll update the man page and changelog later today an push it out for you to play with. Cheers, Simon. Rob ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Feature Request(s)
Works great, thanks for the quick and excellent work Simon! Rob On Fri, Mar 16, 2012 at 9:26 AM, Simon Kelley si...@thekelleys.org.ukwrote: Test release with --host-record is there now: http://www.thekelleys.org.uk/**dnsmasq/test-releases/dnsmasq-** 2.61test5.tar.gzhttp://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.61test5.tar.gz Cheers, Simon. __**_ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.**thekelleys.org.ukDnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.**uk/mailman/listinfo/dnsmasq-**discusshttp://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Feature Request(s)
On Fri, Mar 16, 2012 at 3:10 AM, Simon Kelley si...@thekelleys.org.ukwrote: Perhaps a second expand-host-record to separately enable that? Or a more general expand-records (?) directive that would work for host-record, txt-record, etc... Hmm, maybe. I have a feeling that this is getting complex, especially as the domain added depends on --domain, which can be address-dependent. expand-hosts for /etc/hosts has the justification that (some) OS's work that way when using /etc/hosts outside dnsmasq, for dnsmasq-exclusive config, I'm inclined to keep it simple, especially as it's possible to include a simple name and an expanded name in the same line host-record=laptop, laptop.thekelleys.org.uk, 192.168.0.1 The bind behavior with default expansion and a . to override seems nice, simple intuitive, what about a expand-bind-style directive to turn that behavior on, so as not to break existing syntax, but give that fine grained control to people who want it? That breaks the rule that syntactically different configurations should vary by more than one pixel ;-). Missing the period at the end of a name in a BIND file is almost as annoying as mixing spaces and tabs in a Makefile. I've got the host-record syntax above working fine. I'll update the man page and changelog later today an push it out for you to play with. The syntax you went with works great, it's simple, intuitive, and does the job. I was thinking about dnsmasq syntax and current functionality, the more I think about it, if it was going to do any kind of host expansion, it would be nice to do it in a similar way that bind does it with @ORIGIN, that is to say, multiple @ORIGIN/$TTLs can be specified, and depending on where the RR is located in the config file determines which @ORIGIN/$TTL it uses... I'm guessing that would be require a lot rewriting the way dnsmasq parses the config file, and at some point it's just turning dnsmasq into bind, which it isn't... So, good choice ;) the way it works now is great for my application. Rob ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Feature Request(s)
Maybe take it one step further, --host-record=address,name[,alias,alias,...] so we can keep the CNAMEs right there too. Sounds sensible, as long as multiple --host-record are allowed for one name (multi-homed, IPv4, IPv6) -JP ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Feature Request(s)
On Thu, Mar 15, 2012 at 10:24:44AM -0700, Rob Zwissler wrote: Yah, seems to me it would make more sense to key off the IP address (or have that come first in the config) as it seems to make more sense to organize zone files by IP, and since you can have multiple A's per IP but not multiple IPs per PTR. You CAN have as many PTR records as you want on any name. However, it's unlikely to do anything useful. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Feature Request(s)
On Thu, Mar 15, 2012 at 1:35 PM, Simon Kelley si...@thekelleys.org.ukwrote: All the other DNS record-creation options (txt-record, ptr-record, naptr-record, srv-host, mx-host) take the name as first argument, followed by target(s), so it would be good to follow that, however something more flexible is possible, by allowing an arbitrary number of names followed by an IPv4 address, an IPv6 address, or both --host-record = thekelleys.org, www.thekelleys.org, 1.2.3.4, 1234::11 As usual, the first name gets the PTR record, so 'dig -x 1.2.3.4' returns thekelleys.org in my example. Next question, should expand-hosts work on the names as it does in /etc/hosts, but doesn't in txt-record and friends? Consistency is always nice, so the choice is between consistent behavior across hosts dnsmasq.conf style configs, or consistent behavior within dnsmasq.conf, I'd vote for the latter, so expand-hosts would be ignored for host-record. If it does expand it it for host-record but not txt-record, etc, that seems somewhat un-intuitive. Perhaps a second expand-host-record to separately enable that? Or a more general expand-records (?) directive that would work for host-record, txt-record, etc... The bind behavior with default expansion and a . to override seems nice, simple intuitive, what about a expand-bind-style directive to turn that behavior on, so as not to break existing syntax, but give that fine grained control to people who want it? Rob ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Feature Request(s)
I think he was talking about multiple PTR records for a single IP, not multiple PTR records all returning the same hostname (which agreed, is clearly a reasonable usage). It does look like bind will do it, but seems like an unusual thing to do; although I didn't see an explicit mention of it being poor practice in RFC 1912, or a couple other RFCs I skimmed, but I'm far from a DNS guru. Is there a legitimate use to that? ;; QUESTION SECTION: ;149.50.14.10.in-addr.arpa. IN PTR ;; ANSWER SECTION: 149.50.14.10.in-addr.arpa. 604800 INPTR hostname.domain.com. 149.50.14.10.in-addr.arpa. 604800 INPTR hostname-2.domain.com. regards Rob On Thu, Mar 15, 2012 at 3:27 PM, Ben Finney bignose+hates-s...@benfinney.id.au wrote: /dev/rob0 r...@gmx.co.uk writes: You CAN have as many PTR records as you want on any name. However, it's unlikely to do anything useful. It can be quite useful, since machines can have multiple NICs on the same network (for redundancy, among other reasons) each presenting a different IP address. -- \ “The best way to get information on Usenet is not to ask a | `\ question, but to post the wrong information.” —Aahz | _o__) | Ben Finney ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Feature Request(s)
On Thu, Mar 15, 2012 at 03:14:08PM -0500, richardvo...@gmail.com wrote: On Thu, Mar 15, 2012 at 2:34 PM, /dev/rob0 r...@gmx.co.uk wrote: On Thu, Mar 15, 2012 at 10:24:44AM -0700, Rob Zwissler wrote: Yah, seems to me it would make more sense to key off the IP address (or have that come first in the config) as it seems to make more sense to organize zone files by IP, and since you can have multiple A's per IP but not multiple IPs per PTR. You CAN have as many PTR records as you want on any name. However, it's unlikely to do anything useful. Since the PTR name contains the IP, by definition different IPs means different PTR records. There is nothing preventing you from having as many PTRs on a single in-addr.arpa name as you might wish. Here's a silly example: $ dig 78.247.23.216.in-addr.arpa. any @216.23.247.74 ;; QUESTION SECTION: ;78.247.23.216.in-addr.arpa.IN ANY ;; ANSWER SECTION: 78.247.23.216.in-addr.arpa. 7200 IN SOA ns.slackbuilds.org. hostmaster.ns.slackbuilds.org. 2012031502 28800 7200 864000 7200 78.247.23.216.in-addr.arpa. 7200 IN NS ns2.slackbuilds.org. 78.247.23.216.in-addr.arpa. 7200 IN PTR c78.nodns4.us. 78.247.23.216.in-addr.arpa. 7200 IN PTR look.here.another.ptr.78.247.23.216.in-addr.arpa. 78.247.23.216.in-addr.arpa. 7200 IN PTR third.ptr.wow. 78.247.23.216.in-addr.arpa. 7200 IN A 216.23.247.79 78.247.23.216.in-addr.arpa. 7200 IN TXT A TXT record also. 78.247.23.216.in-addr.arpa. 7200 IN TXT CNAME record is the one thing we cannot do. SOA, NS, three PTRs, A, and two TXTs on that name. Silly stuff, yet quite within the range of DNS legitimacy. My point is, however, that resolvers won't know what to do with multiple PTRs on the same name. Similarly, you can add PTR records in forward zones. There's no limit to the fun, fine in DNS. But no resolver would ask for these PTRs (unless in an RFC 2317 CNAME reference.) See, I even missed the trailing dot on the middle PTR for fun. Or pure sloppiness. :) In 877gylpki8@benfinney.id.au On Fri, Mar 16, 2012 at 09:27:59AM +1100, Ben Finney wrote: /dev/rob0 r...@gmx.co.uk writes: You CAN have as many PTR records as you want on any name. However, it's unlikely to do anything useful. It can be quite useful, since machines can have multiple NICs on the same network (for redundancy, among other reasons) each presenting a different IP address. I thought we were talking about multiple PTRs on the same name. Different IP addresses would mean different in-addr.arpa names. It sounds like you are talking about multiple identical PTR values, where the in-addr.arpa names differ. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Feature Request(s)
On 09/03/12 19:05, Rob Zwissler wrote: Hi Simon - I'm a big fan of DNSMasq, it's great software, thanks all for your hard work. I had three requests/questions I just wanted to throw out there that would come in handy for simplifying configuration in what I think would be an intuitive way. For the most part, this is related to consolidating DNSMasq implementations into a single config file and extending cmd line syntax to reduce reliance on external files. I really like the self contained simple nature of DNSMasq and I won't be happy until it's as powerful and cryptic as Perl ;) 1) address=/domain/ip works great as described, but *.domain and *.*.domain (etc...) also resolv based on this syntax. Syntax like address=/.domain/ip that would prevent *.domain from resolving, or address=/..domain/ip would prevent *.*.domain but allow *.domain, something in that vain, would come in handy. That way, single A records could be overridden with address=/.host/ip so I could keep everything in a single dnsmasq.conf file without maintaining a separate addn-hosts file. Seems like this could extend functionality in a very intuitive, backwards-compatible way without adding much messiness to config or documentation. That's a bit of a minefield: address=/.domain/ and address=/domain/ are equivalent, the former being accepted for backwards-compatibility reasons. There exists a patch which allows full regexps, which takes the line of reasoning to the limit. It's never been included because I thing trying to encode policy on names is wrong, it's too easy end up with the wrong results if you make statement about anything other than a domain. 2) Any reason why an /etc/hosts syntax line can't be put in a dnsmasq.conf file? As far as I can tell it wouldn't break the dnsmasq syntax, and it would allow for consolidating files in a very intuitive, minimalist way. /etc/hosts syntax would be difficult to translate into equivalent command line options, for consistency, something like --a-record = name,address ---record = name, address and --host-record = name, address which does a both forward and backwards would be possible, I've considered this before, but most people seem to like to split off such data into a separate /etc/hosts or another hosts-like file. 3) If #1 #2 aren't feasible, how about something like a=host,ip that would allow for an A/PTR pair in more traditional dnsmasq.conf style syntax, to reduce the need for an addn-hosts file. See above. 4) How come cname= only works for local hosts? Would that be difficult to implement so you could create CNAMEs for A records hosted on upstream servers? It's a real architectural limitation: the data in a reply has to come from only local information, or only upstream information, mixing the two isn't possible. Stub resolvers require both bits of information in one reply. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Feature Request(s)
On Wed, Mar 14, 2012 at 1:07 PM, Simon Kelley si...@thekelleys.org.ukwrote: /etc/hosts syntax would be difficult to translate into equivalent command line options, for consistency, something like --a-record = name,address ---record = name, address and --host-record = name, address which does a both forward and backwards would be possible, I've considered this before, but most people seem to like to split off such data into a separate /etc/hosts or another hosts-like file If you're taking votes, I'd like to see this, it'd be nice to have one centralized file for a dns config. It would be nice to keep SRV/TXT records right next to their matching A record, bind style. Having PTRs in the same file would put you one step above bind :) Maybe take it one step further, --host-record=address,name[,alias,alias,...] so we can keep the CNAMEs right there too. Rob ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Feature Request(s)
Hi Simon - I'm a big fan of DNSMasq, it's great software, thanks all for your hard work. I had three requests/questions I just wanted to throw out there that would come in handy for simplifying configuration in what I think would be an intuitive way. For the most part, this is related to consolidating DNSMasq implementations into a single config file and extending cmd line syntax to reduce reliance on external files. I really like the self contained simple nature of DNSMasq and I won't be happy until it's as powerful and cryptic as Perl ;) 1) address=/domain/ip works great as described, but *.domain and *.*.domain (etc...) also resolv based on this syntax. Syntax like address=/.domain/ip that would prevent *.domain from resolving, or address=/..domain/ip would prevent *.*.domain but allow *.domain, something in that vain, would come in handy. That way, single A records could be overridden with address=/.host/ip so I could keep everything in a single dnsmasq.conf file without maintaining a separate addn-hosts file. Seems like this could extend functionality in a very intuitive, backwards-compatible way without adding much messiness to config or documentation. 2) Any reason why an /etc/hosts syntax line can't be put in a dnsmasq.conf file? As far as I can tell it wouldn't break the dnsmasq syntax, and it would allow for consolidating files in a very intuitive, minimalist way. 3) If #1 #2 aren't feasible, how about something like a=host,ip that would allow for an A/PTR pair in more traditional dnsmasq.conf style syntax, to reduce the need for an addn-hosts file. 4) How come cname= only works for local hosts? Would that be difficult to implement so you could create CNAMEs for A records hosted on upstream servers? regards, Rob ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
