Opened 4 weeks ago

Last modified 4 weeks ago

#1328 assigned request

dns not providing generic rrtypes

Reported by: jholland@… Owned by: sra@…
Priority: tbd Milestone: ietf-106
Component: dns Keywords:
Cc: My Current Location:
My MAC Address: My OS:

Description

Hi,

Today we ran into a problem with the IETF DNS resolvers.

Expected behavior:

$ dig +short -t TYPE260 @1.1.1.1 7.185.212.23.in-addr.arpa
7.v4.driad.akastream2.com.
\# 22 1003047237763403616D7406616B61646E73036E6574

$ dig +short -t TYPE260 @8.8.8.8 7.185.212.23.in-addr.arpa
7.v4.driad.akastream2.com.
\# 22 1003047237763403616D7406616B61646E73036E6574 


Observed behavior (no such field from the default resolvers from
dhcp on ietf network):

$ dig +short -t TYPE260 @31.130.229.6 7.185.212.23.in-addr.arpa
$ dig +short -t TYPE260 @31.130.229.7 7.185.212.23.in-addr.arpa


Thanks,
Jake


Change history (10)

comment:1 Changed 4 weeks ago by odonoghue@…

Component: incomingdns
Owner: changed from < default > to sra@…
Status: newassigned

Thank you for the report. We will look at it first thing in the morning.

comment:2 Changed 4 weeks ago by sra@…

If one drops the +short, it shows up as SERVFAIL. +trace is also somewhat informative. It gets as far as:

7.185.212.23.in-addr.arpa. 7200	IN	CNAME	7.v4.driad.akastream2.com.

then hits a SERVFAIL while trying to resolve the query with the new name.

So there's clearly something wrong, but not immediately obvious where. Investigation continues.

comment:3 Changed 4 weeks ago by sra@…

This is not just IETF: other BIND9 instances SERVFAIL the same way.

comment:4 in reply to:  4 ; Changed 4 weeks ago by jholland@…

On 2019-11-17, 08:28, "IETF Tickets/NOC" <tickets@meeting.ietf.org> wrote:
> This is not just IETF: other BIND9 instances `SERVFAIL` the same way.

That is interesting.  Can you share example resolver IPs?  Most networks
resolve this successfully, but info to follow up on tracking down failures
might be helpful.


comment:5 in reply to:  4 Changed 4 weeks ago by sra@…

This is not just IETF: other BIND9 instances SERVFAIL the same way.

That is interesting. Can you share example resolver IPs?

Not usefully. I don't know of anybody who run BIND9 as a public resolution service, recursive service is usually restricted to local clients (as are the nameservers here at IETF, you just happen to be in the service area at the moment). Our testing here in the NOC was by several of us who operate BIND9 elsewhere. I think all the instances we tested were BIND 9.11, so it's theoretically possible that this has been fixed in a more recent version, but BIND9 has (theoretically) supported opaque RR types for over a decade, so not very likely. You might want to open a ticket with ISC (or we can, if you prefer).

comment:6 Changed 4 weeks ago by sra@…

Should have mentioned: I confirmed that at least one other implementation (unbound) has no difficulty resolving this, so is likely a BIND9 bug rather than something wrong with the data being served. dig whines a bit when testing this, but dnspython has no problem with it (not surprising, given that BIND9 and dig use the same base library code).

comment:7 in reply to:  7 ; Changed 4 weeks ago by jholland@…

If you can track this down to something to open with isc, I'd be grateful if
you open a ticket, thanks for offering.

That said, I'm running a bind9 server in a local network that does resolve this.
Version is as follows:

$ /usr/sbin/named -V
BIND 9.11.3-1ubuntu1.9-Ubuntu (Extended Support Version) <id:a375815>
running on Linux x86_64 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--libexecdir=/usr/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libjson=/usr' '--without-lmdb' '--with-gnu-ld' '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib/softhsm/libsofthsm2.so' '--with-randomdev=/dev/urandom' '--with-eddsa=no' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-cTxvh1/bind9-9.11.3+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 7.4.0
compiled with OpenSSL version: OpenSSL 1.1.1  11 Sep 2018
linked to OpenSSL version: OpenSSL 1.1.1  11 Sep 2018
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with libjson-c version: 0.12.1
linked to libjson-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled



comment:8 in reply to:  8 ; Changed 4 weeks ago by jholland@…

If it's helpful you're welcome to examine my setup, I'm in the
hackathon at the corner table closest to the registry desk.


comment:9 Changed 4 weeks ago by sra@…

That's interesting. By coincidence, all the BIND9 instances we tested were running on FreeBSD. I just tested BIND9 on Ubuntu (16.04) and it worked. Given history with the several open source projects involved, this is less likely to be a FreeBSD issue per se then it is a BIND9 bug which was fixed on Debian or Ubuntu without the patch making it back upstream to ISC. Fun stuff.

comment:10 Changed 4 weeks ago by sra@…

OK. Since one of the failing BIND9 servers tested earlier is a personal server of mine, I upgraded it from BIND 9.11 to BIND 9.14. It now works. So this is something ISC already fixed.

Given that we're already in production mode for IETF 106 we're not likely to upgrade the servers here in Signapore, but we can deal with this by Vancouver.

Note: See TracTickets for help on using tickets.