systemd-resolved doesn't work with "host -l" / AXFR queries

Bug #1854976 reported by Jose Manuel Santamaria Lema on 2019-12-03
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Undecided
Dimitri John Ledkov

Bug Description

Hello,

some time ago network-manager in Ubuntu switched from dnsmasq to systemd-resolved.

When network-manager used dnsmasq to handle DNS, one could use "host -l" to list all the hosts in a DNS zone, something like this:

$ host -l mydomain.lan
mydomain.lan name server mydns.mydomain.lan
host1.mydomain.lan has address x.x.x.x
host2.mydomain.lan has address x.x.x.x
host3.mydomain.lan has address x.x.x.x
host4.mydomain.lan has address x.x.x.x
[...]

That, unfortunately, no longer works since the switch to systemd-resolved, it always fails like this:
$ host -l mydomain.lan
Host mydomain.lan not found: 4(NOTIMP)
; Transfer failed.

And I think that's because systemd-resolved is "filtering" the AXFR queries issued by "host -l" (I checked the network traffic with tcdump and that "NOTIMP" comes from the loopback interface).

Steve Langasek (vorlon) wrote :

An AXFR is not a normal end-user operation, and for most public DNS servers these queries are denied for security reasons. I don't think it's reasonable to expect an AXFR query to work against your local forwarding resolver; I think it was accidental that this worked under dnsmasq.

You should be able to execute a 'host -l' against an actual authoritative nameserver for the domain, if the nameserver is configured to support this, by listing its name as an additional argument to 'host' i.e.:

  host -l mydomain.lan mydns.mydomain.lan

So I think this bug should be closed as 'wontfix', but I'm leaving it for the systemd maintainers to make that determination.

Changed in systemd (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
ghomem (gustavo) wrote :

Hi,

I work with Jose Manuel Santamaria Lema.

Thank you for taking your time to review.

Perhaps we should be a little cautious in regards what we call "normal" and "reasonable". During the last 20+ years of Linux people able were to do "host -l" against servers that were configured to allow so - for example internal name servers that are authoritative for local (LAN related) domains - using directly the local resolver

I would call the ability to do such queries "normal" and "reasonable" because it has been common practice during the last 20+ years. Yesterday was the first time that I have seen the possibility of such queries not working (20.04 early builds). Linux Torvalds usually says "we don't break user space" when changes in the kernel cause problems on user space applications that have certain expectations regarding how the kernel behaves because tradition is some kind of jurisprudence. I feel this is kind of the same situation.

Apart from common practice we could think of other criteria for deciding this. For example what the RFCs say. I am by no mean a DNS authority - please feel free to correct me if I am wrong. Digging little bit I found this:

----

An AXFR query is sent by a client whenever there is a reason to ask.
   This might be because of scheduled or triggered zone maintenance
   activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],
   respectively) or as a result of a command line request, say for
   debugging.

----

Note that it mentions debugging and that ubuntu users are not the average computer "end users" but often a more technical crowd that uses computers to configure and debug. Also, the document refers to "resolvers and servers" and doesn't say AXFR queries are exclusive to authoritative servers.

In that context, does not seek like an accident that it worked with dnsmasq - seems the dnsmasq implemented the feature, like bind and others do.

Reference:

https://tools.ietf.org/html/rfc5936

Lastly, I would say that the decision to downgrade or not the local resolver should come from Ubuntu, rather than systemd. This might not be an "end of the world" situation but still it is a regression that should be assessed, with gains and losses from the resolver change fairly weighted.

Thank you,

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in systemd (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers