Re: [Dnsmasq-discuss] Specific treatment of Class C addresses
Downsides to this proposed change. 1) Old versions of Windows might break. 2) Newer versions of windows might break - we've not done testing on which do and don't. 3) Other platforms which have made the same mistake might break. 4) Dnsmasq installations which unkowningly rely on this behaviour in other respects might break. Upsides to the proposed change. 1) ~1% more available addresses in DHCP pools. 2) A small amount of code which no longer needs maintenance. It's not clear to me what the balance is here. Opinions, list? Simon. On 18/09/2024 18:22, Jan Ceuleers wrote: Dear dnsmasq community, The changelog for version 2.47 contains the following: Don't dynamically allocate DHCP addresses which may break Windows. Addresses which end in .255 or .0 are broken in Windows even when using supernetting. --dhcp-range=192.168.0.1,192.168.1.254,255,255,254.0 means 192.168.0.255 is a valid IP address, but not for Windows. See Microsoft KB281579. We therefore no longer allocate these addresses to avoid hard-to-diagnose problems. Unless I'm mistaken the listed Microsoft KB applies only to Windows versions that are long since past end of support. Furthermore, CIDR was introduced by the IETF more than 30 years ago. I was therefore wondering whether it is time to retire the special treatment of addresses ending in .0 or .255 in Class C address ranges. Many thanks, Jan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH 1/1] forward.c: fix handling of truncated response
I think that this is legitimate behaviour. RFC 2181 para 9 says
Where TC is set, the partial RRSet that would not completely fit may
be left in the response. When a DNS client receives a reply with TC
set, it should ignore that response, and query again, using a
mechanism, such as a TCP connection, that will permit larger replies.
Which means the contents (or lack of them) of the answer, auth and
additional sections has to be ignored by the client anyway.
Do you have a standards reference which says otherwise? Test suites can
tell you either that behaviour has changed over releases or that
behaviour differs from other implementations. They cant tell you that
behaviour is correct.
There is a subtle reason for the code being as it is. Dnsmasq
has various functions which change the contents of a packet being
returned, and these can't reliably be applied to a truncated packet, so
data in a truncated packet may (for instance) disclose DNS data which
should be blocked.
The patch is, in any case, broken because it gratuitously removes the
call to the logging code.
Cheers,
Simon.
On 24/09/2024 11:01, Rahul Thakur via Dnsmasq-discuss wrote:
From: Rahul Thakur
the handling of truncated reponse is broken in 2.90. The answers
are removed before forwarding in case TC bit is set, which
seems incorrect.
test details-
the regression was caught by a CDrouter run and this change fixes
the regression.
---
src/forward.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/src/forward.c b/src/forward.c
index 10e7496..c893d84 100644
--- a/src/forward.c
+++ b/src/forward.c
@@ -782,13 +782,6 @@ static size_t process_reply(struct dns_header *header,
time_t now, struct server
server->flags |= SERV_WARNED_RECURSIVE;
}
- if (header->hb3 & HB3_TC)
-{
- log_query(F_UPSTREAM, NULL, NULL, "truncated", 0);
- header->ancount = htons(0);
- header->nscount = htons(0);
- header->arcount = htons(0);
-}
if (!(header->hb3 & HB3_TC) && (!bogusanswer || (header->hb4 & HB4_CD)))
{
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Specific treatment of Class C addresses
Sorry for the noise, but it should have been: Based on the analysis below, IMO it's not worth it. On Wed, Sep 25, 2024, 04:13 Wink Saville wrote: > Based on the analysis below it's not > IMO it's not worth it. > > Also, the KB has been deleted by > Microsoft. Here[1] is a link to an archived > version of that article. > > > [1]:https://mskb.pkisolutions.com/kb/281579 > > > On Wed, Sep 25, 2024, 02:31 Simon Kelley wrote: > >> Downsides to this proposed change. >> >> 1) Old versions of Windows might break. >> 2) Newer versions of windows might break - we've not done testing on >> which do and don't. >> 3) Other platforms which have made the same mistake might break. >> 4) Dnsmasq installations which unkowningly rely on this behaviour in >> other respects might break. >> >> Upsides to the proposed change. >> 1) ~1% more available addresses in DHCP pools. >> 2) A small amount of code which no longer needs maintenance. >> >> It's not clear to me what the balance is here. Opinions, list? >> >> Simon. >> >> >> >> >> On 18/09/2024 18:22, Jan Ceuleers wrote: >> > Dear dnsmasq community, >> > >> > The changelog for version 2.47 contains the following: >> > >> > Don't dynamically allocate DHCP addresses which may break >> > Windows. Addresses which end in .255 or .0 are broken in >> > Windows even when using supernetting. >> > --dhcp-range=192.168.0.1,192.168.1.254,255,255,254.0 means >> > 192.168.0.255 is a valid IP address, but not for Windows. >> > See Microsoft KB281579. We therefore no longer allocate >> > these addresses to avoid hard-to-diagnose problems. >> > >> > Unless I'm mistaken the listed Microsoft KB applies only to Windows >> versions that are long since past end of support. Furthermore, CIDR was >> introduced by the IETF more than 30 years ago. >> > >> > I was therefore wondering whether it is time to retire the special >> treatment of addresses ending in .0 or .255 in Class C address ranges. >> > >> > Many thanks, Jan >> > >> > >> > ___ >> > Dnsmasq-discuss mailing list >> > Dnsmasq-discuss@lists.thekelleys.org.uk >> > >> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss >> >> >> ___ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss@lists.thekelleys.org.uk >> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss >> >> ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Specific treatment of Class C addresses
Based on the analysis below it's not IMO it's not worth it. Also, the KB has been deleted by Microsoft. Here[1] is a link to an archived version of that article. [1]:https://mskb.pkisolutions.com/kb/281579 On Wed, Sep 25, 2024, 02:31 Simon Kelley wrote: > Downsides to this proposed change. > > 1) Old versions of Windows might break. > 2) Newer versions of windows might break - we've not done testing on > which do and don't. > 3) Other platforms which have made the same mistake might break. > 4) Dnsmasq installations which unkowningly rely on this behaviour in > other respects might break. > > Upsides to the proposed change. > 1) ~1% more available addresses in DHCP pools. > 2) A small amount of code which no longer needs maintenance. > > It's not clear to me what the balance is here. Opinions, list? > > Simon. > > > > > On 18/09/2024 18:22, Jan Ceuleers wrote: > > Dear dnsmasq community, > > > > The changelog for version 2.47 contains the following: > > > > Don't dynamically allocate DHCP addresses which may break > > Windows. Addresses which end in .255 or .0 are broken in > > Windows even when using supernetting. > > --dhcp-range=192.168.0.1,192.168.1.254,255,255,254.0 means > > 192.168.0.255 is a valid IP address, but not for Windows. > > See Microsoft KB281579. We therefore no longer allocate > > these addresses to avoid hard-to-diagnose problems. > > > > Unless I'm mistaken the listed Microsoft KB applies only to Windows > versions that are long since past end of support. Furthermore, CIDR was > introduced by the IETF more than 30 years ago. > > > > I was therefore wondering whether it is time to retire the special > treatment of addresses ending in .0 or .255 in Class C address ranges. > > > > Many thanks, Jan > > > > > > ___ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Specific treatment of Class C addresses
On 25/09/2024 11:06, Simon Kelley wrote: > Downsides to this proposed change. > > 1) Old versions of Windows might break. > 2) Newer versions of windows might break - we've not done testing on > which do and don't. > 3) Other platforms which have made the same mistake might break. > 4) Dnsmasq installations which unkowningly rely on this behaviour in > other respects might break. > > Upsides to the proposed change. > 1) ~1% more available addresses in DHCP pools. > 2) A small amount of code which no longer needs maintenance. > > It's not clear to me what the balance is here. Opinions, list? > > Simon. The reason why I raised this subject is of course the fact that it enables the use of IP addresses in DHCP pools that are not otherwise available for use. IPv4 addresses are a scarce resource, and maximising their use is, in my opinion, a worthy goal. But if the dnsmasq project isn't ready to remove this restriction, would a patch be accepted that makes it configurable? If so, what should the default be? Thanks, Jan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
