[Dnsmasq-discuss] Fwd: mixing synth-domain and auth-domain does not appear to work for me.
On Thu, Apr 3, 2014 at 6:24 AM, Simon Kelley wrote: > > On 02/04/14 11:46, David Beveridge wrote: > > So I have a few static hosts defined in /etc/hosts and I want to > > serve authoritative records for them. > > I also have some machines which get address via dhcp and slaac which I want > > to publish using synth-domain. > > > > Each option works alone, but when I mix the options > > eg > > auth-zone=thekelleys.org.uk,192.168.0.0/24 > > synth-domain=thekelleys.org.uk,192.168.0.0/24,internal- > > > > with synth-domain only > > # dig internal-192-168-0-56.thekelleys.org.uk @223.27.66.79 > > ;; ANSWER SECTION: > > internal-192-168-0-56.thekelleys.org.uk. 0 IN A 192.168.0.56 > > > > with both defined, no answer is returned. > > > > > > The behaviour is the same for Ipv6. > > This is, I think, just an oversight. synth-domain certainly generates > "Locally defined DNS records" which is what the auth-zone is specified > to contain. > So if the auth-domain exists and the lookup fails there it does not try to do a lookup in synth-domain. I'm not sure how commonly people might want to do that. > > > > regards, > > dave. > > > > PS: any reason why synth-domain is limited to /64 for IPv6? > > Prefix length has to be greater than or equal to 64, is that what you > mean? It's about implementation convenience. C doesn't provide a > integer data type larger than 64 bits for doing masking. of the > address-part. > Fair enough. So I have a copy of dnsmasq running on my bind dns server just to handle the synthetic reverse (which bind can't do), so each /64 needs to be individually configured in dnsmasq. It's good to know why. I can't just get lazy and synth a whole /48 or /32. Probably out of scope for what dnsmasq is designed for anyway. dave > Cheers, > > Simon. > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] PTR records with auth-zone and auth-server
I'm using dnsmasq 2.68. It's mostly working, however I'm having a few troubles with PTR records when using auth-zone and auth-server. If I use these options, then: * PTR look-up of IP addresses defined by interface-name=example.lan,br0 return an answer, but the returned status is NXDOMAIN rather than NOERROR. * No custom PTR records can be defined with ptr-record. If I remove the auth-zone and auth-server options, then PTR records work as expected. Is there a good reason that this isn't working when using auth-zone and auth-server options? Regards, Craig McQueen ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] mixing synth-domain and auth-domain does not appear to work for me.
On Thu, Apr 3, 2014 at 6:38 AM, Simon Kelley wrote: > On 02/04/14 21:24, Simon Kelley wrote: > >> >> This is, I think, just an oversight. synth-domain certainly generates >> "Locally defined DNS records" which is what the auth-zone is specified >> to contain. >> > > Actually, there is a reason. It doesn't in general make sense to include > the records created by synth-domain in a zone transfer, since there are > likely to be a lot of them. They could be included in answers for the > auth-zone, at the expense of the additional complication that the zone > answered by dnsmasq becomes no longer exactly the zone that's transfered > to a secondary (since the synth-domain answers can't be included in the > transfer). > I agree, you definitely would not want to zone transfer the entire synth zone just the records from the auth zone. Actually, once you introduce synth records to a zone, transferring it is not practical at all. I think I have misunderstood what auth-zone does. It seems it is not required in this situation. I just tested and discovered that:- If I remove the auth-zone statement from the config file the synth-zone will still serve records it finds in /etc/hosts. In this way I can still have a mixed zone with manually created records and synthesized records in the same zone. The synth-domain kind of implies that the zone is authorative, so no need for the auth-zone statement as well. dave ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnssec on android?
On 03/04/14 02:37, Dave Taht wrote: > It looks like there will be some issues getting dnssec on > on android by switching to dnsmasq: > > https://code.google.com/p/android/issues/detail?id=65510 > > What is dnsmasq's behavior on how/when to switch to tcp? > If the client uses UDP to query dnsmasq, then dnsmasq will use UDP to query upstream. If the client uses TCP to query dnsmasq, then dnsmasq uses TCP to query upstream. The same applies to DNSKEY and DS queries, UDP if the original query came by UDP, TCP if TCP. The normal situation is: client queries dnsmasq over UDP, dnsmasq queries upstream over UDP, repsonse is truncated, truncated response returned to client. Client retries over TCP, dnsmasq queries upstream over TCP, all is good. The same situation applies with DNSSEC, with one additional wrinkle, it's possible that the answer to the actual query comes back untruncated over UDP, but a subsequent query needed to do validation (ie getting DNSKEYS or DS records) is truncated. In this case, dnsmasq marks the original answer as truncated itself and returns it, so that the client will retry using TCP. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 hostname resolving
Hi Simon, Am 02.04.2014 20:34, schrieb Simon Kelley: > Please could you do the following? > > 1) Check the dnsmasq leases file (normally > /var/lib/misc/dnsmasq.leases) to see if the name "atlantis" appears in > the relevant DHCPv6 lease? It only appears for DHCPv4 leases, but not DHCPv6 ones. Here’s the full contents of the lease file: http://pastie.org/8991576 > 2) See if the plain name (not FQDN) resolves > > dig atlantis - ; <<>> DiG 9.9.2-P2 <<>> atlantis ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13397 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;atlantis. IN ;; Query time: 1 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; WHEN: Thu Apr 3 17:31:02 2014 ;; MSG SIZE rcvd: 26 - > 3) See if atlantis.internal.xxx.eu resolves. > > dig atlantis.internal.xxx.eu - ; <<>> DiG 9.9.2-P2 <<>> atlantis.internal.xxx.eu ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55319 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;atlantis.internal.xxx.eu. IN ;; AUTHORITY SECTION: xxx.eu. 2560IN SOA ns.yyy.de. hostmaster.xxx.eu. 1391783412 16384 2048 1048576 2560 ;; Query time: 56 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; WHEN: Thu Apr 3 17:35:04 2014 ;; MSG SIZE rcvd: 124 - - ; <<>> DiG 9.9.2-P2 <<>> atlantis.cable.internal.xxx.eu ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33135 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;atlantis.cable.internal.xxx.eu.IN ;; Query time: 100 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; WHEN: Thu Apr 3 17:31:22 2014 ;; MSG SIZE rcvd: 75 - Normal A records resolve just fine. - ; <<>> DiG 9.9.2-P2 <<>> atlantis A ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31147 ;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;atlantis. IN A ;; ANSWER SECTION: atlantis. 0 IN A 10.37.59.42 ;; Query time: 9 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; WHEN: Thu Apr 3 17:30:55 2014 ;; MSG SIZE rcvd: 42 - - ; <<>> DiG 9.9.2-P2 <<>> atlantis.cable.internal.xxx.eu A ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10528 ;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;atlantis.cable.internal.xxx.eu.IN A ;; ANSWER SECTION: atlantis.cable.internal.xxx.eu. 0 IN A 10.37.59.42 ;; Query time: 1 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; WHEN: Thu Apr 3 17:31:15 2014 ;; MSG SIZE rcvd: 80 - This one (of course) does not: - ; <<>> DiG 9.9.2-P2 <<>> atlantis.internal.xxx.eu A ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27999 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;atlantis.internal.xxx.eu. IN A ;; AUTHORITY SECTION: xxx.eu. 2389IN SOA ns.yyy.de. hostmaster.xxx.eu. 1391783412 16384 2048 1048576 2560 ;; Query time: 35 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; WHEN: Thu Apr 3 17:37:54 2014 ;; MSG SIZE rcvd: 124 - I have however discovered a strange thing. If I send the same queries from another computer (which is in the same subnet and domain), dnsmasq doesn’t resolve the unqualified name: - ; <<>> DiG 9.9.2-P2 <<>> altantis A ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34618 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;altantis. IN A ;; Query time: 1 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; WHEN: Thu Apr 3 17:39:40 2014 ;; MSG SIZE rcvd: 26 - The FQDN is OK: - ; <<>> DiG 9.9.2-P2 <<>> atlantis.cable.internal.xxx.eu A ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6200 ;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;atlantis.cable.internal.xxx.eu.IN A ;; ANSWER SECTION: atlantis.cable.internal
Re: [Dnsmasq-discuss] DHCPv6 hostname resolving
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/14 16:47, Quintus wrote: > Hi Simon, > > Am 02.04.2014 20:34, schrieb Simon Kelley: >> Please could you do the following? >> >> 1) Check the dnsmasq leases file (normally >> /var/lib/misc/dnsmasq.leases) to see if the name "atlantis" >> appears in the relevant DHCPv6 lease? > > It only appears for DHCPv4 leases, but not DHCPv6 ones. Here?s the > full contents of the lease file: http://pastie.org/8991576 OK, that explains why no hostname resolution. I can also explain why the name is not being associated with the lease, it's because you're asking a temporary address lease. I'm not entirely sure why naming is disabled for temporary address leases. I probably thought that it's inherently not sensible to give emphemeral and ever-changing addresses entries in the DNS. Certainly, if there's no other reason not to, you can solve this problem by reconfiguring your client to ask for a non-temporary address. Cheers, Simon. > >> 2) See if the plain name (not FQDN) resolves >> >> dig atlantis > > - ; <<>> DiG 9.9.2-P2 <<>> > atlantis ;; global options: +cmd ;; Got answer: ;; > ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13397 ;; flags: qr > rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: ;atlantis. IN > > ;; Query time: 1 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; WHEN: > Thu Apr 3 17:31:02 2014 ;; MSG SIZE rcvd: 26 > - > >> 3) See if atlantis.internal.xxx.eu resolves. >> >> dig atlantis.internal.xxx.eu > > - ; <<>> DiG 9.9.2-P2 <<>> > atlantis.internal.xxx.eu ;; global options: +cmd ;; Got > answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55319 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: > 0 > > ;; QUESTION SECTION: ;atlantis.internal.xxx.eu. IN > > ;; AUTHORITY SECTION: xxx.eu. 2560IN SOA ns.yyy.de. > hostmaster.xxx.eu. 1391783412 16384 2048 1048576 2560 > > ;; Query time: 56 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; > WHEN: Thu Apr 3 17:35:04 2014 ;; MSG SIZE rcvd: 124 > - > > - ; <<>> DiG 9.9.2-P2 <<>> > atlantis.cable.internal.xxx.eu ;; global options: +cmd ;; Got > answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33135 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, > ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; > QUESTION SECTION: ;atlantis.cable.internal.xxx.eu.IN > > ;; Query time: 100 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; > WHEN: Thu Apr 3 17:31:22 2014 ;; MSG SIZE rcvd: 75 > - > > Normal A records resolve just fine. > > - ; <<>> DiG 9.9.2-P2 <<>> > atlantis A ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- > opcode: QUERY, status: NOERROR, id: 31147 ;; flags: qr aa rd ra ad; > QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: ;atlantis. IN A > > ;; ANSWER SECTION: atlantis. 0 IN A 10.37.59.42 > > ;; Query time: 9 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; WHEN: > Thu Apr 3 17:30:55 2014 ;; MSG SIZE rcvd: 42 > - > > - ; <<>> DiG 9.9.2-P2 <<>> > atlantis.cable.internal.xxx.eu A ;; global options: +cmd ;; Got > answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10528 > ;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, > ADDITIONAL: 0 > > ;; QUESTION SECTION: ;atlantis.cable.internal.xxx.eu. IN A > > ;; ANSWER SECTION: atlantis.cable.internal.xxx.eu.0 IN A > 10.37.59.42 > > ;; Query time: 1 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; WHEN: > Thu Apr 3 17:31:15 2014 ;; MSG SIZE rcvd: 80 > - > > This one (of course) does not: > > - ; <<>> DiG 9.9.2-P2 <<>> > atlantis.internal.xxx.eu A ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27999 ;; > flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: ;atlantis.internal.xxx.eu. IN A > > ;; AUTHORITY SECTION: xxx.eu. 2389IN SOA ns.yyy.de. > hostmaster.xxx.eu. 1391783412 16384 2048 1048576 2560 > > ;; Query time: 35 msec ;; SERVER: 10.37.59.2#53(10.37.59.2) ;; > WHEN: Thu Apr 3 17:37:54 2014 ;; MSG SIZE rcvd: 124 > - > > I have however discovered a strange thing. If I send the same > queries from another computer (which is in the same subnet and > domain), dnsmasq doesn?t resolve the unqualified name: > > - ; <<>
[Dnsmasq-discuss] Using DNSMasq as a DNS sinkhole server
Hi, I want to setup my Raspberry PI as a DNS sinkhole server using DNSMASQ. Does anyone have experience with using DNSMASQ for this purpose? The DNS sinkhole lists are relatively large (currently the list from www[DOT]malware-domains[DOT]com contains about 18000 domains), and my first suspicion was that this might be too big for DNSMASQ to tackle, at least on a raspberry pi. Thanks! BR, Egil Aspevik ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] PTR records with auth-zone and auth-server
On 03/04/14 08:22, Craig McQueen wrote: > I'm using dnsmasq 2.68. It's mostly working, however I'm having a few > troubles with PTR records when using auth-zone and auth-server. If I use > these options, then: > > * PTR look-up of IP addresses defined by interface-name=example.lan,br0 > return an answer, but the returned status is NXDOMAIN rather than NOERROR. That's a bug, nasty one. Fix pushed to git, http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=10068600f889338d942c7206c98e889bb3a17d57 Thanks for the heads-up. > * No custom PTR records can be defined with ptr-record. That's behaving as documented, --ptr-record doesn't appear in the list of data included in an authoritative zone given in the AUTHORITATIVE CONFIGURATION section of the man page. The reason is, I think, that PTR-records can have any name, not just w.x.y.x.in-addr.arpa. It's therefore difficult to use the subnet(s) associated with an auth-zone to filter them. It would be possible to filter on the name using the domain associated with an auth zone, and filter w.x.y.x.in-addr.arpa on the subnet. That's quite complex to understand/document/use. > > If I remove the auth-zone and auth-server options, then PTR records work > as expected. > > Is there a good reason that this isn't working when using auth-zone and > auth-server options? See above: I'm interested in opinions on the PTR thing. Cheers Simon. > > Regards, > Craig McQueen > > > ___ > 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] Per entry TTL override
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/14 22:32, Olivier Mauras wrote: > > > On Mon, 2014-03-31 at 12:59 +0200, Olivier Mauras wrote: >> Hello, >> >> Is it thinkable to allow a per entry TTL override system ? I have >> actually two different needs that i'd like to discuss. First >> NXDOMAINS. I'd like to cache NXDOMAIN from some forwarded domains >> to a specific value. Cache time based on default SOA TTL may be >> too long in some cases and requires a manual cache refresh :( >> Easy example: Infra team provisions a new server and ping the >> hostname asked to see if it's not already taken - Yes they could >> act differently It's not, so result is cached and will stay for >> 1H - default SOA TTL. Server provisioning takes 10mn, and >> hostname is still cached as NX for 50mn :( >> >> Second is entry override. Some specific DNS entries could have a >> different TTL than the default one - But not globally per entry >> gives much more flexibility :) >> >> >> Would that make sense to have a binding for request replies - >> like the dhcp lua script support - or would this make more sense >> as specific harcoded options? If this makes any sense at all >> indeed :) >> >> >> Thanks, Olivier >> >> >> ___ Dnsmasq-discuss >> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > Seemed like i had a double neg-ttl declared in my config and my > command line at the same time which make it to not be correctly > handled... Also seems that no matter what neg-ttl is set to, the > first NXDOMAIN on a cold cache, always get the SOA TTL, am i > missing something ? neg-ttl does not override the SOA TTL, it provides a TTL for NXDOMAIN if the upstream server doesn't include an SOA. (Lots of ISP nameservers seem to strip that information for "bandwidth saving") If you upstream servers include SOA, as they should, then neg-ttl will have no effect. > > > Any feedback on per entry TTL override I'm not sure about that, it seems to me to be fiddly and prone to errors. You first example could be fixed by using --no-negcache. It would be less efficient, but it would always work. If you're going to set a TTL in that case, what's the correct value that will always work? I don't think there is one. I'm interested in other opinions. Cheers, Simon. > > > Thanks, Olivier > > > > ___ Dnsmasq-discuss > mailing list Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM9xqcACgkQKPyGmiibgrf1IACeLu0EOFKHF0AGeALvFtxnSd/6 PUUAnRliZ55VNxqPSyY69h5ytA7KjyEV =UO5/ -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] mixing synth-domain and auth-domain does not appear to work for me.
On 03/04/14 08:35, David Beveridge wrote: > On Thu, Apr 3, 2014 at 6:38 AM, Simon Kelley wrote: >> On 02/04/14 21:24, Simon Kelley wrote: >> >>> >>> This is, I think, just an oversight. synth-domain certainly generates >>> "Locally defined DNS records" which is what the auth-zone is specified >>> to contain. >>> >> >> Actually, there is a reason. It doesn't in general make sense to include >> the records created by synth-domain in a zone transfer, since there are >> likely to be a lot of them. They could be included in answers for the >> auth-zone, at the expense of the additional complication that the zone >> answered by dnsmasq becomes no longer exactly the zone that's transfered >> to a secondary (since the synth-domain answers can't be included in the >> transfer). >> > > I agree, you definitely would not want to zone transfer the entire synth zone > just the records from the auth zone. Actually, once you introduce synth > records to a zone, transferring it is not practical at all. > > I think I have misunderstood what auth-zone does. > It seems it is not required in this situation. > > I just tested and discovered that:- If I remove the auth-zone statement from > the config file the synth-zone will still serve records it finds in > /etc/hosts. > In this way I can still have a mixed zone with manually created records and > synthesized records in the same zone. > > The synth-domain kind of implies that the zone is authorative, > so no need for the auth-zone statement as well. OK. Happy ending :) Cheers, Simon. > > dave > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Fwd: mixing synth-domain and auth-domain does not appear to work for me.
On 03/04/14 08:14, David Beveridge wrote: >> Prefix length has to be greater than or equal to 64, is that what you >> mean? It's about implementation convenience. C doesn't provide a >> integer data type larger than 64 bits for doing masking. of the >> address-part. >> > > Fair enough. So I have a copy of dnsmasq running on my bind dns server > just to handle the synthetic reverse (which bind can't do), so each /64 > needs to be individually configured in dnsmasq. It's good to know why. > > I can't just get lazy and synth a whole /48 or /32. > Probably out of scope for what dnsmasq is designed for anyway. That's what I told myself when I wrote the code, it's crazy to use arbitary-precision maths in a DNS daemon. Then a year later I implemented DNSSEC which uses public-key crypto, based in arbitrary-precision maths :-) Cheers, Simon. > > dave > >> Cheers, >> >> Simon. >> > > ___ > 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] Per entry TTL override
On Thu, 2014-04-03 at 21:37 +0100, Simon Kelley wrote: > On 02/04/14 22:32, Olivier Mauras wrote: > > > > > > On Mon, 2014-03-31 at 12:59 +0200, Olivier Mauras wrote: > >> Hello, > >> > >> Is it thinkable to allow a per entry TTL override system ? I have > >> actually two different needs that i'd like to discuss. First > >> NXDOMAINS. I'd like to cache NXDOMAIN from some forwarded domains > >> to a specific value. Cache time based on default SOA TTL may be > >> too long in some cases and requires a manual cache refresh :( > >> Easy example: Infra team provisions a new server and ping the > >> hostname asked to see if it's not already taken - Yes they could > >> act differently It's not, so result is cached and will stay for > >> 1H - default SOA TTL. Server provisioning takes 10mn, and > >> hostname is still cached as NX for 50mn :( > >> > >> Second is entry override. Some specific DNS entries could have a > >> different TTL than the default one - But not globally per entry > >> gives much more flexibility :) > >> > >> > >> Would that make sense to have a binding for request replies - > >> like the dhcp lua script support - or would this make more sense > >> as specific harcoded options? If this makes any sense at all > >> indeed :) > >> > >> > >> Thanks, Olivier > >> > >> > >> ___ Dnsmasq-discuss > >> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk > >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > Seemed like i had a double neg-ttl declared in my config and my > > command line at the same time which make it to not be correctly > > handled... Also seems that no matter what neg-ttl is set to, the > > first NXDOMAIN on a cold cache, always get the SOA TTL, am i > > missing something ? > > neg-ttl does not override the SOA TTL, it provides a TTL for NXDOMAIN > if the upstream server doesn't include an SOA. (Lots of ISP > nameservers seem to strip that information for "bandwidth saving") If > you upstream servers include SOA, as they should, then neg-ttl will > have no effect. > > > > > > Any feedback on per entry TTL override > > I'm not sure about that, it seems to me to be fiddly and prone to > errors. You first example could be fixed by using --no-negcache. It > would be less efficient, but it would always work. If you're going to > set a TTL in that case, what's the correct value that will always > work? I don't think there is one. > > I'm interested in other opinions. > > > Cheers, > > > Simon. > > > > > > > Thanks, Olivier > > > > > > > > ___ 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 True that no-negcache would fix my first example, but wouldn't caching for a definite time be more efficient? I actually have weird behavior when cascading dnsmasq instances. 127.0.0.1 forwarding to a dnsmasq instance, forwarding to an unbound server... 127.0.0.1 on first query receives the SOA TTL, but as the forwarded dnsmasq instance has cached, it returns 0 as TTL. So clearing cache on 127.0.0.1 and asking again same query will return with neg-ttl as the TTL. I agree it's pretty particular but having a "neg-cache-ttl" would prevent this _and_ be efficient enough :) That was for NXDOMAINS, what about overriding TTL for standard entry? opinions? Thanks, Olivier signature.asc Description: This is a digitally signed message part ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] PTR records with auth-zone and auth-server
On 04/04/14 07:28, Simon Kelley wrote: On 03/04/14 08:22, Craig McQueen wrote: * No custom PTR records can be defined with ptr-record. That's behaving as documented, --ptr-record doesn't appear in the list of data included in an authoritative zone given in the AUTHORITATIVE CONFIGURATION section of the man page. The reason is, I think, that PTR-records can have any name, not just w.x.y.x.in-addr.arpa. It's therefore difficult to use the subnet(s) associated with an auth-zone to filter them. It would be possible to filter on the name using the domain associated with an auth zone, and filter w.x.y.x.in-addr.arpa on the subnet. That's quite complex to understand/document/use. DNS-SD (RFC 6763) makes use of PTR records that end in the domain name. E.g. ending in example.com.: _http._tcp.example.com. lb._dns-sd._udp.example.com. DNS-SD also makes use of PTR records that end in the reverse mapping name of the network address of the subnet. E.g. for subnet 192.168.5.0/24, some PTR records ending in 0.5.168.192.in-addr.arpa.: b._dns-sd._udp.0.5.168.192.in-addr.arpa. lb._dns-sd._udp.0.5.168.192.in-addr.arpa. It would be good to allow ptr-record options that match either of these cases. The first case (ending in example.com.) should be straight-forward. The reverse case should also be okay, unless I'm overlooking some complication. I haven't looked into the IPv6 case. DNS-SD also uses SRV and TXT records, ending in .example.com. Thanks, Craig McQueen ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
