[PATCH V2]networking: Allow dot at the end of the domain name in dhcp response

Balaji Punnuru balaji.punnuru at gmail.com
Tue Feb 9 17:23:59 UTC 2016


When a dhcp server responds with a domain name that ends with a ".",
domain name validation is failing which leads to populating domain bad in
resolv.conf

Domain name ending with . is a valid syntax according RFC-1034.

The Patch fixes the domain name validation which ends with "."
The test results are as follows:

1. if DNS server returns with domain name "foo.test.com." , resolv.conf
gets populated with "domain foo.test.com."

2. if DNS server returns with domain name "foo.test.com" , resolv.conf gets
populated with "domain foo.test.com"

Without this Patch:
1. if DNS server returns with domain name "foo.test.com." , resolv.conf
gets populated with "domain bad <http://foo.test.com>"

2. if DNS server returns with domain name "foo.test.com" , resolv.conf gets
populated with "domain foo.test.com"


Details: In Some instances where DNS Servers sends out domain name
         in answer with a terminating ".", the validation logic for
         domain name is returning as bad domain.

         According to RFC 1034 Section 3.1, a character string
         which represents a complete domain name(often called "absolute").
         For example, "poneria.ISI.EDU."

         The fix done is to add a check for end of string after
         processing node which allows for presence of "." at the end of the
string

Signed-off-by: Balaji Punnuru <balaji_punnuru at cable.comcast.com>
---
 networking/udhcp/dhcpc.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/networking/udhcp/dhcpc.c b/networking/udhcp/dhcpc.c
index 915f659..3d5b245 100644
--- a/networking/udhcp/dhcpc.c
+++ b/networking/udhcp/dhcpc.c
@@ -201,6 +201,18 @@ static int good_hostname(const char *name)
             //Do we want this?
             //return ((name - start) < 1025); /* NS_MAXDNAME */
         name++;
+                /*
+                   According to RFC 1034, section 3.1, trailing dots is
allowed,
+
+                   Quoting from RFC 1034:
+                   ----------------------
+                   The most common interpretation uses the root "." as
either the
+                   single origin or as one of the members of the search
list, so
+                   a multi-label relative name is often one where the
trailing dot
+                   has been omitted to save typing.
+                */
+        if (*name == '\0')
+            return 1;
     }
 }
 #else
-- 
2.1.4
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20160209/5fdc5b05/attachment.html>


More information about the busybox mailing list