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

[Marc Heckmann]

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=<glue_record>,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

[Simon Kelley]

Post by Marc Heckmann
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=<glue_record>,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.

Post by Marc Heckmann
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Marc Heckmann]

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?

-m

Post by Simon Kelley

Post by Marc Heckmann
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=<glue_record>,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.

Post by Marc Heckmann
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Simon Kelley]

Post by Marc Heckmann
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....

Simon.

Post by Marc Heckmann
-m

Post by Marc Heckmann
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 &

Post by Marc Heckmann
auth-zone configuration options for this. This works as expected

and is

Post by Marc Heckmann
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=<glue_record>,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

Post by Marc Heckmann
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

Post by Marc Heckmann
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

Post by Marc Heckmann
and authoritative service from the same interface? I can

understand the

Post by Marc Heckmann
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.

Post by Marc Heckmann
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Eric Luehrsen]

Post by Simon Kelley

Post by Marc Heckmann
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....
Simon.

Post by Marc Heckmann
-m

Post by Marc Heckmann
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 &

Post by Marc Heckmann
auth-zone configuration options for this. This works as expected

and is

Post by Marc Heckmann
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=<glue_record>,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

Post by Marc Heckmann
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

Post by Marc Heckmann
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

Post by Marc Heckmann
and authoritative service from the same interface? I can

understand the

Post by Marc Heckmann
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

In other software something like the following makes a reasonable
non-functioning default, when things go wrong. It terminates locally
instead of whatever root-as-NS will cause.
7200 IN SOA localhost. nobody.invalid. 1 3600 1200 9600 300
7200 IN NS localhost.

[Geert Stappers]

Post by Eric Luehrsen

Post by Simon Kelley

Post by Marc Heckmann
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....

In other software something like the following makes a reasonable
non-functioning default, when things go wrong. It terminates locally instead
of whatever root-as-NS will cause.
7200 IN SOA localhost. nobody.invalid. 1 3600 1200 9600 300
7200 IN NS localhost.

And what A record for Name Server 'localhost.' ?



Groeten
Geert Stappers

[Simon Kelley]

Post by Simon Kelley

Post by Marc Heckmann
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.

Post by Simon Kelley
Simon.

Post by Marc Heckmann
-m

Post by Marc Heckmann
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 &

Post by Marc Heckmann
auth-zone configuration options for this. This works as expected

and is

Post by Marc Heckmann
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=<glue_record>,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

Post by Marc Heckmann
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

Post by Marc Heckmann
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

Post by Marc Heckmann
and authoritative service from the same interface? I can

understand the

Post by Marc Heckmann
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.

Post by Marc Heckmann
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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