From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTP id 422A25A026F for ; Thu, 21 Sep 2023 17:08:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695308907; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5Pm32rAB01l88TffOX8YHNCMq6CT2kotvjEZ7h9DNzY=; b=aGL1AA5m3KxDGjhPpkmrJcFzUXcrJVVibGxohK/EYWYgBSaANdKxZOsMs/cpmPcWyHw6j/ mK7mC5HdhTObkkBdpT/463XCGSV3oY3nQxjGs8I8d+8TzLbxcFtK/PSBYMqUi040L6I43H UiYYjWP+A37dQNeXYH4MnntaC0UXOwQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-533-jgJIiuP_PvGrOgb21wPrmw-1; Thu, 21 Sep 2023 11:08:25 -0400 X-MC-Unique: jgJIiuP_PvGrOgb21wPrmw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 123C41019C88; Thu, 21 Sep 2023 15:08:25 +0000 (UTC) Received: from elisabeth (unknown [10.39.208.36]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 34D652156701; Thu, 21 Sep 2023 15:08:23 +0000 (UTC) Date: Thu, 21 Sep 2023 17:08:22 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] dhcpv6: Properly separate domain names in search list Message-ID: <20230921170822.46c441f2@elisabeth> In-Reply-To: References: <20230920150506.3341961-1-sbrivio@redhat.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: H47SVQOVC7D7L3VGXQCA5MVRQMRGC4IP X-Message-ID-Hash: H47SVQOVC7D7L3VGXQCA5MVRQMRGC4IP X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top, Sebastian Mitterle X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, 21 Sep 2023 09:55:11 +1000 David Gibson wrote: > On Wed, Sep 20, 2023 at 05:05:06PM +0200, Stefano Brivio wrote: > > If we go over the flattened list of search domains and just replace > > dots and zero bytes with the length of the next label to implement > > the encoding specified by section 3.1 of RFC 1035, if there are > > multiple domains in the search list, we'll also replace separators > > between two domain names with the length of the first label of the > > second domain, plus one. > > That is... an impressively long sentence. Any chance you could reword > that in shorter ones that are easier to follow ;). Oops. :) What about: To prepare the DHCPv6 domain search list option, we go over the flattened list of domains, and replace both dots and zero bytes with a counter of bytes in the next label, implementing the encoding specified by section 3.1 of RFC 1035. If there are multiple domains in the list, however, zero bytes serve as markers for the end of a domain name, and we'll replace them with the length of the first label of the next domain, plus one. This is wrong. We should only convert the dots before the labels. ? > > Those should remain as zero bytes to > > separate domains, though. > > > > To distinguish between label separators and domain names separators, > > for simplicity, introduce a dot before the first label of every > > domain we copy to form the list. All dots are then replaced by label > > lengths, and separators (zero bytes) remain as they are. > > > > As we do this, we need to make sure we don't replace the trailing > > dot, if present: that's already a separator. Skip copying it, and > > just add separators as needed. > > > > Now that we don't copy those, though, we might end up with > > zero-length domains: skip them, as they're meaningless anyway. > > > > And as we might skip domains, we can't use the index 'i' to check if > > we're at the beginning of the option -- use 'srch' instead. > > > > This is very similar to how we prepare the list for NDP option 31, > > except that we don't need padding (RFC 8106, 5.2) here, and we should > > refactor this into common functions, but it probably makes sense to > > rework the NDP responder (https://bugs.passt.top/show_bug.cgi?id=21) > > first. > > > > Reported-by: Sebastian Mitterle > > Link: https://bugs.passt.top/show_bug.cgi?id=75 > > Signed-off-by: Stefano Brivio > > --- > > dhcpv6.c | 24 +++++++++++++++++------- > > 1 file changed, 17 insertions(+), 7 deletions(-) > > > > diff --git a/dhcpv6.c b/dhcpv6.c > > index fc42a84..58171bb 100644 > > --- a/dhcpv6.c > > +++ b/dhcpv6.c > > @@ -376,24 +376,34 @@ search: > > return offset; > > > > for (i = 0; *c->dns_search[i].n; i++) { > > - if (!i) { > > + size_t name_len = strlen(c->dns_search[i].n); > > + > > + /* We already append separators, don't duplicate if present */ > > + if (c->dns_search[i].n[name_len - 1] == '.') > > + name_len--; > > + > > + /* Skip root-only search domains */ > > + if (!name_len) > > + continue; > > Should we consider doing this normalisation when we build > c->dns_search, rather than here? I quickly looked at that, but it complicates the (insane) compression scheme from RFC 1035 4.1.4 implemented by the DHCP server -- and also we would need to convert them back before printing them. I don't think it's necessarily a bad idea though. I guess we should have a few explicit functions to convert between different encodings and then stick to the storage format that turns out to be the most convenient. But that's beyond the scope of this fix. -- Stefano