Bug 1647464

see also https://gitlab.isc.org/isc-projects/bind9/issues/668

Ok, I am not sure what exactly is

obviously upstream decided to implement some arbitary changes breaking setups which worked for years and you can no longer delegate a subdomain to a machine running dnsmasq feeded by /etc/hosts instead of fully implement dns-zones for each and every development subdomain

it's pervert that upstream calls that as "fixed something"

What issue is here? Could you explain your configuration more? It is not clear what exactly are you trying to accomplish to me. I can see guys at ISC already locked your issue.

I can understand that using /etc/hosts is a quite nice feature. I use it to manage local instances of VM on my machine. Well, dnsmasq is somehow deficient in usual configuration. I still have do discovery how to work it out correctly.

If you choose to use name server delegation instead of forwarding, auth-server has to be used. If not, dnsmasq records have to be used carefully.

Could you provide how is configured dnsmasq?

I think it is expected from recursive servers to send queries without recursive flag set. That exactly BIND does and I think that exactly dnsmasq does not accept. That is the difference between forward configured in bind (which sends recursive flag set) and authoritative delegation (with is not recursive).

Would this also return requested address?
$ dig +norec contentlounge.flow-home.example.com. @192.168.196.244

no, that is a SERVFAIL and i am reqally pissed that that worked for years without anny issues

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41465
;; flags: qr ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

[root@flow-home:~]$ cat /etc/dnsmasq.conf
resolv-file=/etc/resolv.conf.dnsmasq
all-servers
no-poll
user=dnsmasq
group=dnsmasq
local-ttl=604800
neg-ttl=300
cache-size=5000
dns-forward-max=150

the problem is obvisouly that dnsmasq gives back idiotic errors and named was "fixed to death"

(In reply to Harald Reindl from comment #3)
> obviously upstream decided to implement some arbitary changes breaking
> setups which worked for years and you can no longer delegate a subdomain to
> a machine running dnsmasq feeded by /etc/hosts instead of fully implement
> dns-zones for each and every development subdomain
> 
> it's pervert that upstream calls that as "fixed something"

Depends on your setup. I am sure it still can configured somehow, I have myself test domain forwarded between unbound, bind and dnsmasq. You can delegate anything you want. Question is, is dnsmasq able to handle such delegation? AFAIK dnsmasq has no concept of zones built-in. It is more or less smart caching daemon that forwards everything to real resolver somewhere. I think it is problem of dnsmasq or its configuration.

Can you make record queries done by bind to dnsmasq and its responses?
Something like:
$ tcpdump -s0 -i tunX -v host 192.168.196.244 and port domain

it would help you if you had in your bind instead something like:

zone "flow-home.example.com." IN {
  type forward;
  forward only;
  forwarders { 192.168.196.244; };
};

I understand that is not as handy as one record in your zone, but it would work instead. It can be scripted to autogenerate into some file in /etc/named/vpn-forwards.conf for example, included from /etc/named.conf.

the point is that it worked before without needing dnsmasq a "zone concept" and the whole configuration including 800 auth-domains *is* auto-generated 

this is a subdomain of our MAIN-DOMAIN and as i tested it yesterday the forward-only didn't work either, don't know if it's because the main zone exists auto-generated in a different zone-file, anyways it sucks that all the time things are brfeaking right and left and developers at the same time call it a fix

Can you try adding to dnsmasq

auth-server=openvpn-flow.example.com,192.168.196.244
auth-zone=flow-home.example.com
auth-soa=1

restart dnsmasq and retry dig with +norec flag?

yeah that does the trick - you are my hero of the day

auth-zone=flow-home.example.com
auth-zone=flow.example.com
auth-soa=1

/etc/hosts and /etc/dnsmasq.conf are synced between two machines
both zones are now working again with a NS-record in named pointing to the host

"dig NS" treuns only a dot but as long as clients got served that's fine :-)

content of the zone in named
flow                            IN A            192.168.196.215
flow-home                       IN A            192.168.196.244
flow                            IN NS           flow
flow-home                       IN NS           flow-home

BTW: that is for sure a bug in "dnsmasq"

nslookup is asking fro both, A and AAAA and dnsmasq responds with REFUSED instead NXDOMAIN in case it's configured to not use forwarders (dnsmasq[140020]: warning: no upstream servers configured) which appears taht otherwise it's asking the upstream server and giving back the NXDOMAIN from upstream

[root@testserver:~]$ nslookup webmail.testserver.rhsoft.net 127.0.0.1
Server:         127.0.0.1
Address:        127.0.0.1#53
Name:   webmail.testserver.rhsoft.net
Address: 127.0.0.1
** server can't find webmail.testserver.rhsoft.net: REFUSED

user=dnsmasq
group=dnsmasq
interface=lo
bind-interfaces
no-resolv
no-hosts
addn-hosts=/etc/hosts.dnsmasq
local-ttl=30
auth-ttl=30

-----------------------

[root@testserver:~]$ dig A webmail.testserver.rhsoft.net @127.0.0.1

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-10.P2.fc28 <<>> A webmail.testserver.rhsoft.net @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60626
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;webmail.testserver.rhsoft.net. IN      A

;; ANSWER SECTION:
webmail.testserver.rhsoft.net. 30 IN    A       127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fr Nov 09 13:58:10 CET 2018
;; MSG SIZE  rcvd: 74

-----------------------

[root@testserver:~]$ dig AAAA webmail.testserver.rhsoft.net @127.0.0.1

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-10.P2.fc28 <<>> AAAA webmail.testserver.rhsoft.net @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 6627
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;webmail.testserver.rhsoft.net. IN      AAAA

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fr Nov 09 13:58:15 CET 2018
;; MSG SIZE  rcvd: 47

Non-recursive queries were disabled to prevent cache snooping in dnsmasq. That is the reason for REFUSED. Anything registered locally should respond, but without recursion desired flag no other reply is anwered.

Auth-zone is required to respond with NXDOMAIN in question to non-existent record in given zone. It tells dnsmasq it is authoritative for all names under given zone, which is exactly your use case here. It knows there is no reason why should forward it to upstream servers.

If no upstream servers are configured, it may help to configure it as authoritative for everything: auth-zone=.

But I would stick to limited zone.

but it should not respond with REFUSED when asked for AAAA while an A-record for the same name exists from /etc/hosts

According to my testing, dnsmasq does not respond with REFUSED when responding to query without query. However, it responds strange to dig +norec requests to records written in /etc/hosts. It seems non-recursive requests do not respond with records from hosts file, but recursive does.

Created attachment 1554819 [details]
restore replies to non-recursive queries

It might be REFUSED, because queries without recursion desired flag set are always forwarded to "upstream" servers.

Heck, I would call this recursion, and this behaves in exact opposite the flag is for. I doubt such behaviour is intentional. With +rec, it serves local records, but with +norec it serves always upstream records if there are any. If upstream is again dnsmasq, it would return REFUSED.

Posted proposed fix to upstream

1. http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013010.html
2. http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013013.html
3. http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013015.html

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Reopening this issue, is not fixed in dnsmasq yet even in latest version.

Merged upstream under commit [1].

1. http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=29ae3083981ea82f535f77ea54bbd538f1224a9e

dnsmasq-2.80-12.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aab29ac03c

dnsmasq-2.80-12.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

FEDORA-2020-b6287eafe3 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b6287eafe3

FEDORA-2020-b6287eafe3 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b6287eafe3

FEDORA-2020-b21d576a15 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b21d576a15

FEDORA-2020-d85dcb2efc has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d85dcb2efc`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d85dcb2efc

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-b21d576a15 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-b21d576a15`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b21d576a15

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-b6287eafe3 has been pushed to the Fedora 30 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-b6287eafe3`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b6287eafe3

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-b21d576a15 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-d85dcb2efc has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-d85dcb2efc has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-b6287eafe3 has been pushed to the Fedora 30 stable repository.
If problem still persists, please make note of it in this bug report.