[Dnsmasq-discuss] Patch with option to filter A records

[Simon Kelley]

On 02/09/2021 21:18, Trey Sis wrote:
> On 7/9/2021 17:46, Geert Stappers via Dnsmasq-discuss wrote:
>> On Fri, Jul 09, 2021 at 02:35:29PM +0200, Petr Menšík wrote:
>>> On 6/16/21 1:26 PM, Trey Sis wrote:
>>>> On 6/14/2021 1:43, Trey Sis wrote:
>>>>> On 6/13/2021 22:01, Geert Stappers wrote:
>>>>>> warning: 1 line adds whitespace errors.
>>>>> My bad! Fixed. Find the new patch attached to this message.
>>>>>
>>>> Hello everyone,
>>>>
>>>> I was wondering if anyone has any suggestions or objections for the
>>>> patch?
>>>>
>>>> I still think it would be very valuable for many setups out there to
>>>> drop A records. Most OS don't query for AAAA if there is no IPv6
>>>> connection. But none don't query for A if there is no IPv4. That often
>>>> causes problems with applications that did not (yet) implement happy
>>>> eyeballs. Getting this upstream would make it much easier to handle
>>>> IPv6-only environments.
>>>>
>>>> What do you think?
>>>>
>>> Hi Trey,
>>>
>>> Are there any specific applications requiring this patch? It seems to me
>>> most of work should be spent on applications not handling IPv4 addresses
>>> correctly. Also, I would implement filtering of both address families if
>>> it is required.
>>>
>>> Are there specific applications, where we can help escalate the problem
>>> on their side instead?  As you have already said, when they ask for A
>>> address, they should receive one. Whether it is useful or not, clients
>>> should be able to process it. And skipping to IPv6 in case of no IPv4
>>> connectivity should be immediate. We lack full IPv6 connectivity at
>>> office, so far I know only svn is not able to switch to IPv4 only. Which
>>> is solved by switching to git. Filtering of AAAA record would have
>>> solved it too.
>>>
>>>
>> Quoting post that started this email thread:
>>
>> } I have created a patch that adds an option to dnsmasq to filter
>> } out A record requests. This is particularly suitable for IPv6-only
>> } environments. Some software (especially NodeJS) will reorder DNS
>> } requests giving priority to A records,       irrespective of IPv4
>> } connectivity of the host. My patch filters A records, while AAAA
>> } records are returned.
>>
>> Short answer to
>>> Do you have examples of applications, where this change would help?
>> NodeJS
> 
> Alright, so I have found the time now to rebase this patch against the
> current branch.
> 
> I can only repeat that it would be make a lot of folks happy to have
> this patch included, even if they're not on this mailing list. It's
> mostly NodeJS applications, but other apps as well. It's often not clear
> what would work. So this patch would also be helpful in development
> environments when testing IPv6 compatibility with software.
> 
> I would really love to have some feedback if you are missing some detail.
> 
> Cheers,
> 

So, this patch looks for questions which are for an A record, and always
returns a NODATA answer.

That's not strictly correct.


If we have a domain which doesn't exist, say no-such-domain.example.com

The answer to a query for that will be NXDOMAIN, which means that the
domain doesn't exist, and queries for any type of RR will always fail.

A sensible DNS client which sees that will not repeat queries for that
name with other RR types.

With this patch, a query for A no-such-domain.example.com will get a
NODATA response, which implies that there's no A record, but there are
other records, so the client will try for other types. That's
inefficient, but worse, if the client then tries for an AAAA record (for
instance) it will get an NXDOMAIN response. At this point the client is
seeing inconsistent responses from the DNS and all bets are off.

Always returning an NXDOMAIN response is worse, of course, since if that
happens with a domain which does have other RR types, they will
effectively deleted by the wrong NXDOMAIN.

The correct way to do this is to send the query upstream, and then when
the reply comes back, delete any A records from the reply before it's
returned to the original requestor, (and before it's cached.) The hard
work of doing this has been done in src/rrfilter.c, it just needs
another mode which deletes A records from the answer section only.

A patch which does that (and has an option to do the same thing for AAAA
records) and has suitable man page additions, I'd certainly take. It's
in the dnsmasq tradition of providing tools to usefully edit the view of
the DNS seen by downstream clients.



Cheers,


Simon.