View Issue Details

IDProjectCategoryView StatusLast Update
0003261unrealircdpublic2015-07-19 19:10
Reporteravb Assigned Tosyzop  
Status resolvedResolutionfixed 
OSAnyOS VersionAny 
Product Version3.2.6 
Fixed 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


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



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
2) Request forward DNS, get IP
3) Connect to IP 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, get (rarely when you have a dynamic hostname does your reverse dns point to it instead of an ISP-controlled hostname).
7) Does == ? 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 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)


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 {
  ip *@*;
  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 connects
reverse dns for is
forward dns for verified to be
ircd authentications

that it should ignore reverse dns, and resolve the forward hostname, to check for a match (link block for has forwardresolve flag):
ip connects
forward dns for the hostname is resolved to
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


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 "".

Server 1 named "", Server 2 named "",

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 - that resolves to
Server 2 - that resolves to

In this example server 1 act's as IRC Hub, and Server 2 connects to server 1

Server 1 has link block named "" with link::hostname = ""

1) Server 2 starting connection to Server 1 (
2) Server 2 requests forward DNS, get IP
3) Connect to IP
4) Server 1 accepted connection, authenticate.
6) Hostname check: Server 1 looks for FORWARD resolve of
Does 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.


2015-07-19 19:09

administrator   ~0018530


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