Re: [Dnsmasq-discuss] Authoritative and recursive service from the same interface

[Simon Kelley]

On 28/09/18 23:46, Simon Kelley wrote:
> On 28/09/18 23:07, Marc Heckmann wrote:
>> Very nice, I will test this.
>>
>> I am curious though: what will be used for the NS record if the
>> auth-server configuration is omitted?
> 
> 
> It appears to return an NS record of "." ie the DNS root. Which is not
> particularly sensible. This may need some more thought
> 


With a little more clarity of thought, it's clear that omitting
auth-server is not sensible, but it should be possible to omit the
interface name(s) from auth-server.

I just pushed an update which does this: it crashes with an error if an
auth-zone is defined bu there is no auth-server. It allows auth-server
to have no interface-names or addresses, just the glue record domain name.



Cheers,

Simon.

> Simon.
> 
>>
>> -m
>>
>>
>> On Fri, Sep 28, 2018 at 4:42 PM Simon Kelley > > wrote:
>>
>> On 28/09/18 02:33, Marc Heckmann wrote:
>> > Hello,
>> >
>> > I'm currently running dnsmasq in a Docker container and have setup a
>> > domain for which dnsmasq is to be authoritative for. This is to do
>> > subdomain delegation to the dnsmasq server. I am using the
>> auth-server &
>> > auth-zone configuration options for this. This works as expected
>> and is
>> > verifiable using dig with the "+norecurse" option to query for the NS
>> > and SOA records. However, as it's a Docker container, I only have and
>> > actually need a single interface (eth0) and when I specify eth0 in the
>> > "auth-server" option, i.e "auth-server=,eth0", I noticed
>> > that it stops answering recursive queries for names that it is not
>> > authoritative for.
>> >
>> > I worked around this by replacing "eth0" with an IP that is not
>> present
>> > in the container's network namespace and dnsmasq now does what I want
>> > which is to answer to both non-recursive and recursive queries
>> from the
>> > same interface.
>> >
>> > My question is the following: Are there any side effects to this hack?
>> > Is there any reason why dnsmasq should not be able to provide
>> recursive
>> > and authoritative service from the same interface? I can
>> understand the
>> > security reasons for wanting to prevent this on an Internet exposed
>> > interface, but why not at allow for an option to officially support
>> > providing both kinds of service on the same interface?
>> >
>> > Thanks.
>> >
>> > -m
>> >
>> >
>>
>>
>> This patch, in the pending 2.80 release, addresses this, is allows you
>> to omit the auth-server configuration and get both recursive and
>> authoritative answers on the interface(s) that dnsmasq is listening on.
>>
>> 
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=397c0502e255ea0a470982666dea93e0b2f52043
>>
>>
>>
>> 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
>>
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] TCP DNSSEC request over IPv6 abandoned in v2.79

[Simon Kelley]

On 05/10/18 06:06, Josh Soref wrote:
> Simon Kelley  wrote:
>> You say "When I perform DNSSEC validation over IPv6" which implies, but
>> doesn't state, that the same test works when talking to usptream DNS
>> servers over IPv4? Is that the case? Certainly, a quick test here works
>> over IPv4. I'm wondering if I need to resurrect my severely bit-rotted
>> IPv6 tunnel setup?
> 
> Fwiw, I found https://tunnelbroker.net/ to be very easy to set up...
> (Everything else related to dns is harder...)
> 

I used to use sixxs, but that's gone now.

My ISP (EE) seems to be rolling out IPv6, so it might be best to try and
get the stuff at this end set up for that. Being mobile makes it all
more difficult.



Cheers,

Simon.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Duplicate IP detection with fixed IP

[Bernard CLABOTS]

Hi Simon,   Sorry to come back to this question again. You wrote:"I don't think 
it would be possible to make this hack any more safe by
doing the ping-check before re-creating the lease. The whole premise is
that the client attempting to renew is already configured, but the
server lost track of it. So doing a ping-check would expect to get a
reply from the already-configured client."

Well, actually, I see at least two ways to improve that behavior, especially 
starting from the fact that assuming that the lease dB was corrupted is weird 
and not safe:
1. ARP the IP to see if you receive any answer other than the client asking the 
IP (more efficient but fails if using proxy arp).
2. PING the IP and expect to receive an answer from that same MAC (might fail 
if device is set to not answer ping).
if not, then reject and force 4 way. Indeed, if you receive no answer, you can 
no longer assume that this is the legit owner of the IP. Anyway, if the client 
is legitimate, the algorithm will most probably give him the same IP.
The main drawback is an increased handling time, but that only occurs if the 
lease is unknown.

 

On Wednesday, 19 September 2018, 13:01, Simon Kelley 
 wrote:
 

 

On 19/09/18 11:09, Bernard CLABOTS wrote:
> Thanks a lot for this answer.
> 
> Indeed, it is a special case as we have a simple two way Request/ACK,
> this is also what is seen with some implementations when quickly
> unplugging/re-plugging the cable, it is legal AFAIK.
> 
> I also agree on the necessity to be efficient in case of loss of the
> lease dB.
> 
> Yet reading the RFC-2131, I saw:
>   If the client's request is invalid (e.g., the client has moved
>   to a new subnet), servers SHOULD respond with a DHCPNAK message to
>   the client. Servers SHOULD NOT respond if their information is not
>   guaranteed to be accurate.  For example, a server that identifies a
>   request for an expired binding that is owned by another server SHOULD
>   NOT respond with a DHCPNAK unless the servers are using an explicit
>   mechanism to maintain coherency among the servers.
> 
> **//___^Referring to the first sentence, I agree it is only a should.
> Though, the next sentence is, according to your explanation, also
> relevant in this case, so DNSMasq should not respond if the information
> is not guaranteed to be accurate. Which also means that changing the
> authoritative flag, we risk to end up in the exemplified case where
> DNSMasq cannot guarantee that the requested IP is belonging to another
> DHCP Server, so it should not NAK and we are going in circles...
> We can of course discuss whether the Request is invalid simply because
> that IP is currently used by another device while not even assigned
> through DHCP. I would argue that the DNSMasq code explicitly accept that
> requesting the IP of the server fulfills this condition, which IMHO is a
> similar case.
> **//___^
> Anyhow, moving forward to resolve the issue I face, is there any way to
> force the RFC behavior of NAK-ing and forcing the 4 way exchange?
> 

If you don't set dhcp-authoritative, then the client will eventually
move to the four-way exchange, but it may take some time, as it involves
time-outs. The reason for this is that the dnsmasq server has to assume
there are other DHCP servers on the network which may hold a lease for
the client.

The differences in behaviour are these.

Without dhcp-authoritative:

1) A client sending DHCPREQUEST in init-reboot state which doesn't have
a lease in the database will be ignored.

2) A client sending a DHCPREQUEST in rebind mode which doesn't have a
lease in the database will be ignored. In renew mode (ie unicast
request) it will get a DHCPNAK.

3) A client sending a request with the wrong server-id will be ignored.

With dhcp-authoritative

1) A client sending DHCPREQUEST in init-reboot state which doesn't have
a lease will have the lease created

2) A client sending a DHCPREQUEST in renew or rebind mode which doesn't
have a lease in the database will have a lease created.

3)  A client sending a request in INIT_REBOOT or SELECTING state with
the wrong server-id will get a DHCPNAK.


Cheers,

Simon.




   ___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss