Opened 5 years ago

Closed 5 years ago

#3779 closed defect (fixed)

Client FQDN with empty "Domain Name"

Reported by: nicolas.chaigneau Owned by: tmark
Priority: medium Milestone: Kea0.9.2-beta
Component: Unclassified Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

A client provides option 81 (Client FQDN) with an empty "Domain Name" string.

The following error appears in Kea logs:

2015-03-27 13:10:32.234 ERROR [kea-dhcp4.dhcp4/26604] DHCP4_NAME_GEN_UPDATE_FAIL failed to update the lease after generating name for a client: failed to update the lease with address 10.156.0.2 - no such lease

And two lines are added to the lease file:

10.156.0.2,4e:43:48:00:00:01,,1800,1427459662,1001,0,0,
10.156.0.2,4e:43:48:00:00:01,,1800,1427459662,1001,0,0,myhost-10-156-0-2.

(If the client provides a non empty "Domain Name" in option 81, the error does not appear, and only one line is added to the lease file.)

This is with the following configuration:

"dhcp-ddns": {

"enable-updates": false

},

Subtickets

Change History (10)

comment:1 follow-up: Changed 5 years ago by tmark

Check the RFC(s) and see if a blank domain name in client supplied FQDN is legal and if so what it means.

comment:2 in reply to: ↑ 1 Changed 5 years ago by nicolas.chaigneau

Replying to tmark:

Check the RFC(s) and see if a blank domain name in client supplied FQDN is legal and if so what it means.

It's legal, see:

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

A client MAY also leave the Domain Name field empty if it desires the
server to provide a name.

comment:3 Changed 5 years ago by hschempf

  • Milestone changed from Kea-proposed to Kea0.9.2

comment:4 Changed 5 years ago by tmark

  • Owner set to tmark
  • Status changed from new to assigned

comment:5 Changed 5 years ago by tmark

  • Owner changed from tmark to UnAssigned
  • Status changed from assigned to reviewing

When the client supplies a blank name the server is supposed to generate the FQDN. Since generated FQDNs must include the lease IP address, the server first allocates the lease and then updates it with the generated FQDN. Currently the logic attempts to update the lease with generated name whether it is responding to a DISCOVER or a REQUEST. In the case of the former, the lease has not been saved to the database (fake_allocation flag is true), so attempting to find it fails.

Correcting this was a minor matter of modifying the server logic update the database only when fake allocation flag is false.

It is actually "correct" for the lease file to contain two entries when FQDN is being generated. The first entry occurs when the lease is allocated, and the second when the lease is updated with the generated name.

It might be worth investigating modifying the logic such that the allocation engine can generate the name rather than the higher level server logic updating afterwords. I have
created ticket #3581 with additional notes to look into this further.

Ticket is ready for review.

comment:6 Changed 5 years ago by marcin

  • Owner changed from UnAssigned to marcin

comment:7 follow-up: Changed 5 years ago by marcin

  • Owner changed from marcin to tmark

Reviewed d5fe442c84aca5a9094a4fad3e88474ccf10cc81

src/bin/dhcp4/tests/fqdn_unittest.cc
The key of this change is to conditionally update the lease when the DHCPREQUEST has been received. It may be worth to add additional test cases for empty FQDN with the DHCPREQUEST message. The test should check that the lease has been updated in the database with the generated FQDN value.

Note: you can force the client to send DHCPREQUEST by performing doDORA(). It would effectively perform 4-way exchange.

The other thing is to make sure that the lease is NOT in the database when you just do DHCPDISCOVER (currently present test case).

Please propose the ChangeLog entry.

comment:8 in reply to: ↑ 7 Changed 5 years ago by tmark

  • Owner changed from tmark to marcin

Replying to marcin:

Reviewed d5fe442c84aca5a9094a4fad3e88474ccf10cc81

src/bin/dhcp4/tests/fqdn_unittest.cc
The key of this change is to conditionally update the lease when the DHCPREQUEST has been received. It may be worth to add additional test cases for empty FQDN with the DHCPREQUEST message. The test should check that the lease has been updated in the database with the generated FQDN value.

Note: you can force the client to send DHCPREQUEST by performing doDORA(). It would effectively perform 4-way exchange.

The other thing is to make sure that the lease is NOT in the database when you just do DHCPDISCOVER (currently present test case).

Done.

Please propose the ChangeLog entry.

xxx.    [bug]   tmark
    DHCPv4 no longer attempts to update the lease database with the 
    generated FQDN  when processing DISCOVERs.  
    (Trac #3779, git TBD)

comment:9 Changed 5 years ago by marcin

  • Owner changed from marcin to tmark

Reviewed commit e87dc1e7c7a8ce6b8de7910d9c0457847f828c69

src/bin/dhcp4/tests/fqdn_unittest.cc

emptyDomain test comments: replace REQUEST with DHCPREQUEST

replace expectedAddress with expected_address throughout the test

replace expectedFqdn with expected_fqdn throughout the test

ChangeLog
I suggest to replace "DISCOVERs" with "DHCPDISCOVER messages".

Changes are minor, so I don't need to see this ticket again.

comment:10 Changed 5 years ago by tmark

  • Resolution set to fixed
  • Status changed from reviewing to closed

Changes addressed and merged with commit 0b413ee8aba1afa1643b216a1e8c35103c6c975b.

Added ChangeLog entry 927.

Note: See TracTickets for help on using tickets.