View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003261 | unreal | ircd | public | 2007-03-14 03:15 | 2015-07-19 19:10 |
| Reporter | avb | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| OS | Any | OS Version | Any | ||
| Product Version | 3.2.6 | ||||
| Fixed in Version | 3.4-beta2 | ||||
| Summary | 0003261: [Feature request] Support for DNS hostname check in the link::hostname for INCOMING connections | ||||
| Description | I'm understand that dns queries can slow down connections, but, can it be implemented as an optional feature? it can provide flexible centralized link management (via DNS) - for example with this feature we can modify servers ip-addresses without modifying config files (that can take long time in some cases), and also it can provide additional protection from hub-admins abusing their rights (we can just delete or modify A-records in DNS to "disconnect" some hub). in any case i'm think that this is good feature | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
The only reason dynamic hostnames don't work in a link::hostname is this (assuming DNS request on incoming was done): 1) Starting connection to my.other.server.network.tld. 2) Request forward DNS, get IP 1.2.3.4 3) Connect to IP 1.2.3.4:6669 or whatever your server port is. 4) Connection accepted, authenticate. 5) Start identd and hostname requests, as if this connection had been received. 6) Hostname check: Reverse DNS IP 1.2.3.4, get 4-3-2-1.myisp.net (rarely when you have a dynamic hostname does your reverse dns point to it instead of an ISP-controlled hostname). 7) Does 4-3-2-1.myisp.net == my.other.server.network.tld ? No. Authentication fails. (Of course, this assumed unreal even did the DNS in the first place. If not then it'll just try to match 1.2.3.4 to the hostname, which still fails.) link::options::nohostcheck resolves this by preventing hostname check, but has the downside that it makes link::hostname effectively the same as *. It could be possible (if not already) to use a hostname and have it checked, but only if the reverse DNS of the IP goes back to that hostname. (edit: The same above is true for receiving connections, identd/hostname check goes off, unreal compares ISP host against dynamic host, fails, kills link) |
|
|
take this link block for example (ignore the fact that its not complete): link irc.example.com { ip *@*; hostname example.com; flags { forwardresolve; }; }; i think what avb means (maybe he doesn't but...) is that, there should be a flag, where, instead of doing the dns in the typical order for incoming connections: ip 1.2.3.4 connects reverse dns for 1.2.3.4 is example.com forward dns for example.com verified to be 1.2.3.4 ircd authentications that it should ignore reverse dns, and resolve the forward hostname, to check for a match (link block for example.com has forwardresolve flag): ip 1.2.3.4 connects forward dns for the hostname example.com is resolved to 1.2.3.4 ircd authenticates not sure if that made sense or not, but i think that may be what avb was saying. this would allow the ircd to make sure that a dynamic host is the correct ip, without needing to rely on the reverse dns |
|
|
Thanks djGrrr. I'm imagined auth. via DNS in the following way: All names are invented just for example. For Example - We have two servers - "Server 1" and "Server 2" and IRC network named "SomeNet" with domain name "someirc.net". Server 1 named "irc.server1.net", Server 2 named "irc.server2.net", we also have domain names used for linking (which are controlled by irc network administrators)(if we want to change server IP-Address - we only need to change DNS A or CNAME record, without modifying ircd config file) Server 1 - server1.lnk.someirc.net that resolves to 1.1.1.1 Server 2 - server2.lnk.someirc.net that resolves to 2.2.2.2. In this example server 1 act's as IRC Hub, and Server 2 connects to server 1 Server 1 has link block named "irc.server2.net" with link::hostname = "server2.lnk.someirc.net" 1) Server 2 starting connection to Server 1 (server1.lnk.someirc.net) 2) Server 2 requests forward DNS, get IP 1.1.1.1 3) Connect to IP 1.1.1.1:PORT 4) Server 1 accepted connection, authenticate. 6) Hostname check: Server 1 looks for FORWARD resolve of server2.lnk.someirc.net Does server2.lnk.someirc.net IN A (or IN CNAME and after it IN A) match IP address from which incoming connection originates? Refuse. if not. in addition - if hostname in the link block (on server that receiving connection), resolves to multiple ip addresses it is enough that incoming connection originate from one of them - this also allow us to set fixed list of ip addreses, from which connections are permitted, and modify it (the list) via DNS, without changing ircd configuration. |
|
|
Done. https://github.com/unrealircd/unrealircd/commit/8b039335d6b8d508818f9ee15fd139a81fe23d42 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-03-14 03:15 | avb | New Issue | |
| 2007-03-24 10:36 | aquanight | Note Added: 0013326 | |
| 2007-03-24 10:37 | aquanight | Note Edited: 0013326 | |
| 2007-03-24 11:59 | djGrrr | Note Added: 0013330 | |
| 2007-03-24 12:02 | djGrrr | Note Edited: 0013330 | |
| 2007-03-29 16:13 | avb | Note Added: 0013335 | |
| 2007-03-29 16:17 | avb | Note Edited: 0013335 | |
| 2007-03-30 10:44 | avb | Note Edited: 0013335 | |
| 2007-04-18 05:30 |
|
Status | new => acknowledged |
| 2007-04-18 05:35 |
|
Relationship added | related to 0003260 |
| 2007-05-04 08:58 |
|
Relationship added | related to 0003315 |
| 2015-07-19 19:09 | syzop | Note Added: 0018530 | |
| 2015-07-19 19:09 | syzop | Status | acknowledged => resolved |
| 2015-07-19 19:09 | syzop | Fixed in Version | => 3.4-beta2 |
| 2015-07-19 19:09 | syzop | Resolution | open => fixed |
| 2015-07-19 19:09 | syzop | Assigned To | => syzop |
