View Issue Details

IDProjectCategoryView StatusLast Update
0003261unrealircdpublic2015-07-19 19:10
ReporteravbAssigned Tosyzop 
PrioritynormalSeverityminorReproducibilityN/A
Status resolvedResolutionfixed 
PlatformOSAnyOS VersionAny
Product Version3.2.6 
Target VersionFixed in Version3.4-beta2 
Summary0003261: [Feature request] Support for DNS hostname check in the link::hostname for INCOMING connections
DescriptionI'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
TagsNo tags attached.
3rd party modules

Relationships

related to 0003260 closed [Feature request] Support for CIDR and/or masking in the link::hostname 
related to 0003315 closed Document link::options::nohostcheck 

Activities

aquanight

2007-03-24 10:36

reporter   ~0013326

Last edited: 2007-03-24 10:37

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)

djGrrr

2007-03-24 11:59

reporter   ~0013330

Last edited: 2007-03-24 12:02

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

avb

2007-03-29 16:13

reporter   ~0013335

Last edited: 2007-03-30 10:44

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.

syzop

2015-07-19 19:09

administrator   ~0018530

Done.

https://github.com/unrealircd/unrealircd/commit/8b039335d6b8d508818f9ee15fd139a81fe23d42

Issue History

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 stskeeps Status new => acknowledged
2007-04-18 05:35 stskeeps Relationship added related to 0003260
2007-05-04 08:58 stskeeps 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