bind vs glue records

[Stephen Borrill]

With netbsd-7, BIND 9.10.2-P4 and using root.cache with no forwarders, I'm
seeing problems with a few sites that have suspect glue records. I cannot
recreate the problem with netbsd-5 and its in-base BIND. Upstream
recursive servers such as Google don't have problems and so NetBSD is
getting the blame from end-users.

Example domains are:
static.acer.com
bmb.secure.barclays.com
download.adobe.com

# host static.acer.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

Host static.acer.com not found: 3(NXDOMAIN)
# host static.acer.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

static.acer.com is an alias for static-akamai.gtm.acer.com.
static-akamai.gtm.acer.com is an alias for wac.15D43.taucdn.net.
wac.15D43.taucdn.net is an alias for gp1.wac.v2cdn.net.
gp1.wac.v2cdn.net has address 93.184.220.20

On netbsd-7:
# /etc/rc.d/named restart
Stopping named.
Waiting for PIDS: 29737.
Starting named.
# dig static.acer.com

; <<>> DiG 9.10.2-P4 <<>> static.acer.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31266
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;static.acer.com. IN A

;; ANSWER SECTION:
static.acer.com. 86400 IN CNAME
static-akamai.gtm.acer.com.

;; AUTHORITY SECTION:
gtm.acer.com. 60 IN SOA gtm1.acer.com.
hostmaster.gtm1.acer.com. 686 10800 3600 604800 60

;; Query time: 1263 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Mar 24 16:39:50 GMT 2016
;; MSG SIZE rcvd: 128


On netbsd-5:
# /etc/rc.d/named restart
Stopping named.
Waiting for PIDS: 87.
Starting named.
# dig static.acer.com

; <<>> DiG 9.5.2-P2 <<>> static.acer.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20858
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;static.acer.com. IN A

;; ANSWER SECTION:
static.acer.com. 86400 IN CNAME
static-akamai.gtm.acer.com.
static-akamai.gtm.acer.com. 30 IN CNAME wac.15D43.taucdn.net.
wac.15D43.taucdn.net. 3600 IN CNAME gp1.wac.v2cdn.net.
gp1.wac.v2cdn.net. 3600 IN A 93.184.220.20

;; AUTHORITY SECTION:
v2cdn.net. 172800 IN NS ns1.v2cdn.net.
v2cdn.net. 172800 IN NS ns2.v2cdn.net.

;; Query time: 623 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Thu Mar 24 16:40:50 2016
;; MSG SIZE rcvd: 179

[Robert Elz]

Date: Thu, 24 Mar 2016 16:41:58 +0000 (GMT)
From: Stephen Borrill <***@precedence.co.uk>
Message-ID: <***@ugly.internal.precedence.co.uk>

| With netbsd-7, BIND 9.10.2-P4 and using root.cache with no forwarders, I'm
| seeing problems with a few sites that have suspect glue records.

Are you sure that is related to glue?

In the DNS the value (the canonical name) of a CNAME record is not
supposed to be an alias (a name with a CNAME record attached).

That is, the DNS admin is supposed to chase chains (not that there
ever should be more than 1 to follow) of CNAME records when entering
the CNAME, just that once, rather than having every lookup have to
go hunting through a chain of CNAMES (of potentially unlimited length)
trying to find the answer.

When doing a lookup, if a CNAME is found, its value must bee used to
obtain the answer, if another CNAME appears, it is perfectly acceptable
for the resolver to report an error.

Whether that happens or not in common implementations tends to depend upon
all kinds of details about just how things happen, and what was chached,
and when. But no-one should be depending upon it happening to work.

Glue is a record added to a zone that does not belong to the zone, but
which is required in order to make things work (eg: the A or AAAA records
for a nameserver in the parent zone, where the nameserver is in the
delegated child zone - but in order to find the address of the nameserver
(without the glue)you would first need to find the address of the nameserver
so you could ask it...) That's why it is called glue - it does not really
belong, but it is needed to hold things together...

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jeremy C. Reed]

I tracked your problem down in master (upcoming 9.11) when cookies
support is enabled by default. I can also reproduce it in bind 9.10 when
experimental SIT support (using an experimental option code) is enabled.
(SIT is BIND9 experiment predating Cookies.)

This is enabled by default on NetBSD. (It is not enabled by default with
BIND 9.10 from ISC.) See src/external/bsd/bind/include/isc/platform.h

#define ISC_PLATFORM_USESIT 1

Change that to an #undef ISC_PLATFORM_USESIT

and it should work for you. (Note there are some other SIT or AES
settings also enabled related to it in config.h.)

As a workaround, set in your options in named.conf:

request-sit false;

(Be sure to flush your cache after that.)

The problem can easily be seen currently by doing:

dig +nosit bmb.glbaa.barclays.com. @157.83.102.245
(returns A record)

dig +sit bmb.glbaa.barclays.com. @157.83.102.245
(no response)

(I was able to reproduce with some of the other examples too.)

But regardless of NetBSD using this experimental code, the real code is
on by default in upcoming BIND 9.11 and has same problem. I will
research some more and let you know.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jeremy C. Reed]

Post by Jeremy C. Reed
(no response)

More information ... a few of the nameservers timeout (don't respond) on
the cookie (or SIT). And the one that finally responds, returns the
NXDOMAIN. (If +nocookie, they all do send back an answer.)

Here is an example of a response that could happen:
http://www.kb.cert.org/vuls/id/714121
(CERT issued an advisory because some DNS servers responded with wrong
message.)

Also see
https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue
about problems like this.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mike Pumford]

Post by Jeremy C. Reed
request-sit false;

That works perfectly for me here for now. Thanks for tracking that one
down. I suspect I might never have noticed this until Stephen pointed
this out and I'd certainly not have tracked it down without help. :)

Would NetBSD 6.x have had the same problem? Up until recently one of my
2 servers was 6.x rather than 7.x which might have masked this.

Post by Jeremy C. Reed
But regardless of NetBSD using this experimental code, the real code is
on by default in upcoming BIND 9.11 and has same problem. I will
research some more and let you know.

Good to know. Having just done a quick scan I coulnd't see documentation
for 9.11 yet (I guess it won't appear until it gets released) I can't
see if this option will continue to work in that release do you know if
it will?

Mike

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jeremy C. Reed]

Post by Mike Pumford

Post by Jeremy C. Reed
request-sit false;

That works perfectly for me here for now. Thanks for tracking that one
down. I suspect I might never have noticed this until Stephen pointed
this out and I'd certainly not have tracked it down without help. :)

No problem.

Post by Mike Pumford
Would NetBSD 6.x have had the same problem? Up until recently one of my 2
servers was 6.x rather than 7.x which might have masked this.

Not currently -- I think it has older BIND. (I did hear some talk about
upgrading it and that is what prompted me to followup on this.)

Post by Mike Pumford

Post by Jeremy C. Reed
But regardless of NetBSD using this experimental code, the real code is
on by default in upcoming BIND 9.11 and has same problem. I will
research some more and let you know.

Good to know. Having just done a quick scan I coulnd't see
documentation for 9.11 yet (I guess it won't appear until it gets
released) I can't see if this option will continue to work in that
release do you know if it will?

The alpha docs are at: https://ftp.isc.org/isc/bind9/9.11.0a1/doc/arm/
In particular see
https://ftp.isc.org/isc/bind9/9.11.0a1/doc/arm/Bv9ARM.ch06.html
about send-cookie. (No, the experimental "sit" option won't work on 9.11
as the naming of the feature was changed.)

(The best idea would be to complain to these nameserver operators that
return an NXDOMAIN or don't respond at all.)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de