[SNMP4J] TRANSPORT-ADDRESS-MIB: TransportAddressDns

[Frank Fock]

Hi Bruno,

You are right, the default implementation does not support the DNS 
transport domains
as it should. However, you can - at any time - register your own 
TDomainAddressFactory
at the SnmpTargetMIB to add support for it.

I will add support in the default implementation for the DNS transport 
domains
for the next release which will be available later this week.

Best regards,
Frank

Am 22.02.2016 um 11:36 schrieb Bruno Leite:
> Hi,
>
> First of all, thank you for your effort developing and maintaining snmp4j.
>
> To give a little bit of context, I was recently requested to make a configuration change on a snmp4j-agent running on one of our services. The request was basically to change the destination address of SNMP traps, but instead of using an IPv4 or IPv6 address we needed to use a fully qualified domain name (i.e. nms.example.com <http://nms.example.com/>). After checking the TRANSPORT-ADDRESS-MIB definition I saw that there was a “transportDomainUdpDns” object which seemed to match exactly our requirement:
>
> "The UDP transport domain using fully qualified domain
> names. The corresponding transport address is of type
> TransportAddressDns."
>
>
> After changing the snmp4j-agent configuration to use “transportDomainUdpDns” (OID: 1.3.6.1.2.1.100.1.14) I noticed that traps were not being delivered nor any DNS resolution was being made. The configuration looks like this:
>
> ## snmpTargetAddrTable
> snmp4j.agent.cfg.oid.1.3.6.1.6.3.12.1.2.1=1:8
> snmp4j.agent.cfg.index.1.3.6.1.6.3.12.1.2.1.0={o}'notify3'
> snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.2.1.0.0={o}1.3.6.1.2.1.100.1.14
> snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.2.1.0.1={x}6e:6d:73:2e:65:78:61:6d:70:6c:65:2e:63:6f:6d:00:A2
> snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.2.1.0.2={i}1000
> snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.2.1.0.3={i}1
> snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.2.1.0.4={s}notify
> snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.2.1.0.5={s}SNMPv3
> snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.2.1.0.6={i}4
> snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.2.1.0.7={i}1
>
>
> Looking into the code (TDomainAddressFactoryImpl), it seems that the snmp4j-agent is able to handle the “transportDomainUdpDns” :
>
> if (TransportDomains.snmpUDPDomain.equals(transportDomain) ||
>      TransportDomains.transportDomainTcpDns.equals(transportDomain) ||
>      TransportDomains.transportDomainUdpDns.equals(transportDomain) ||
>      TransportDomains.transportDomainUdpIpv4.equals(transportDomain) ||
>      TransportDomains.transportDomainTcpIpv4.equals(transportDomain) ||
>      TransportDomains.transportDomainUdpIpv6.equals(transportDomain) ||
>      TransportDomains.transportDomainTcpIpv6.equals(transportDomain)) {
>    TransportIpAddress transportIpAddress;
>    if (TransportDomains.transportDomainTcpIpv4.equals(transportDomain) ||
>        TransportDomains.transportDomainTcpIpv6.equals(transportDomain) ||
>        TransportDomains.transportDomainTcpDns.equals(transportDomain)) {
>      transportIpAddress = new TcpAddress();
>    }
>    else {
>      transportIpAddress = new UdpAddress();
>    }
>    try {
>      transportIpAddress.setTransportAddress(address);
>    }
>
> However when setting the transport address (last line of above code) it always tries to decode the address as an IPv4 or IPv6 address (without resolving it). As per the TransportIpAddress class, the address is always parsed with:
>
> InetAddress.getByAddress(addr)
>
>
> Am I missing some configuration or could this really be an issue? Shouldn’t the “transportDomainTcpDns” and “transportDomainUdpDns” have a different handling mechanism (which should involve resolving the domain name)?
>
> Thanks for your support.
>
> Best Regards,
> Bruno Leite
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

-- 
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231