sbyx / ohybridproxy Goto Github PK

In b_query_start() in dns2mdns.c there are tests as to whether the request comes from a known domain or from ".arpa". If it is from a known domain, the domain is re-written to ".local" by TO_MDNS(). But it isn't re-written if it is ".arpa". This means that we can't do mDNS queries to ".local" from home domains ".home.arpa" which is now the recommended home domain name by RFC8375.

Looking back, the test seems to be introduced in https://github.com/sbyx/ohybridproxy/blob/9315f7b98b984e00977e4c7de5f572ed5ebc6c37/src/dns2mdns.c and some later revisions says it is done because of a bug in mdnsResponder.

Can you provide some howtos what i need to run to get things working?
For example what part of mDNSResponder i need to keep run, what cmdline for ohybridproxy in this case...
I want to forward mdns request from dnsmasq to this proxy.

i cant for the life of me figure out what parts of mDNSResponder are needed to build that dependency.

figured it out

I've noticed that if I query Homenet my router y for an IN A record belonging to a host attached router x, no answer is forthcoming. However, if I ask x directly, I do get an answer:

$ dig +short @y.home. lust.e1.x.home. IN A
$ dig +short @x.home. lust.e1.x.home. IN A
10.0.0.115

Running tcpdump on the transit link between x and y reveals that y does forward the request to x and that it does receive an answer:

08:48:17.832315 IP6 2a02:fe0:c410:d9d::54.19148 > 2a02:fe0:c410:d95::38.domain: 41578+ [1au] A? lust.e1.x.home. (43)
08:48:17.832753 IP6 2a02:fe0:c410:d95::38.domain > 2a02:fe0:c410:d9d::54.19148: 41578* 1/0/1 A 10.0.0.115 (59)

However logread on y reveals what's going wrong here:

Tue Oct 13 08:48:17 2015 daemon.warn dnsmasq[3551]: possible DNS-rebind attack detected: lust.e1.x.home

Adding list rebind_domain 'home' to the config dnsmasq section in /etc/config/dhcp on y successfully works around this problem. In my opinion, this should be made the default (at least if Homenet software is installed).

My ISP did maintenance today. That essentially broke internal communication in my homenet. I'll try to explain what happened below.

Background: My ISP provides native dual-stack. So normally, a host is assigned with a total of four addresses (ignoring link-locals and privacy extensions):

1. An DHCPv6 IA_NA-assigned address from the ISP prefix (let's assume 2001:db8::547)
2. A SLAAC-assigned address from the ISP prefix
3. A SLAAC-assigned ULA address
4. A private IPv4 address out of 10.0.0.0/8

In the normal situation, the host's host.port1.rtr1.home. name resolves to two of the above (1 and 4).

However, when the uplink to the ISP goes away, things start happening. The ISP-assigned IPv6 prefix is deprecated, and IPv4 stops working completely. Furthermore, the AAAA record of host.port1.rtr1.home. changes from 2001:db8::547 to an ULA address like fd00::547 - which isn't assigned to any local interface on the host at all. I assume that this address is the one the host would end up receiving if it were to restart its DHCPv6 client, but this doesn't happen automatically just because the ISP was disconnected.

This means that any attempt to contact host.port1.rtr1.home. from another host somewhere else in the homenet ends up failing while the ISP link is down.

I assume avoiding this situation is precisely the reason why ULAs are used in the first place. However, I think that in order for this to actually work, the IA_NA handed out by the DHCPv6 server probably needs to be from the ULA prefix even though the ISP connection is up, so that it will continue working after an ISP is down.

23:11:02.388508 gettimeofday({1442005862, 389747}, NULL) = 0
23:11:02.390098 gettimeofday({1442005862, 390595}, NULL) = 0
23:11:02.390886 gettimeofday({1442005862, 391374}, NULL) = 0
23:11:02.391678 _newselect(1096, [3 4 6 9 1025 1027 1028 1029 1030 1031 1032 1033 1034 1039 1041 1042 1043 1056 1060 1061 1067 1068 1070 1071 1072 1073 1088 1089 1090 1094], NULL, NULL, {952314, 251953}) = -1 EBADF (Bad file descriptor)
23:11:02.393239 rt_sigprocmask(SIG_BLOCK, [HUP INT PIPE TERM USR1], NULL, 16) = 0
23:11:02.394087 rt_sigprocmask(SIG_UNBLOCK, [HUP INT PIPE TERM USR1], NULL, 16) = 0
23:11:02.394899 gettimeofday({1442005862, 395385}, NULL) = 0
23:11:02.395667 gettimeofday({1442005862, 396154}, NULL) = 0
23:11:02.396456 gettimeofday({1442005862, 396940}, NULL) = 0
23:11:02.397220 gettimeofday({1442005862, 397804}, NULL) = 0
23:11:02.398129 gettimeofday({1442005862, 398740}, NULL) = 0
23:11:02.399077 _newselect(1096, [3 4 6 9 1025 1027 1028 1029 1030 1031 1032 1033 1034 1039 1041 1042 1043 1058 1059 1061 1063 1064 1067 1068 1069 1071 1072 1073 1088 1089 1090 1094], NULL, NULL, {952314, 244140}) = -1 EBADF (Bad file descriptor)
23:11:02.401086 rt_sigprocmask(SIG_BLOCK, [HUP INT PIPE TERM USR1], NULL, 16) = 0

thoughts: do we have too many FDs? (=ratelimit mdnsresponder requests?)

is there mdnsresponder bug?