Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

direct queries of reverse zone, [not] using CNAME hack

39 views
Skip to first unread message

Justin Pryzby

unread,
Aug 27, 2008, 2:25:42 PM8/27/08
to
Hi Everyone,

We have CIDR/29 reverse DNS delegated to us using the CNAME hack:

> 109.216.80.206.in-addr.arpa is an alias for 109.104-111.216.80.206.in-addr.arpa.
> 109.104-111.216.80.206.in-addr.arpa domain name pointer athena.norchemlab.com.

Every day we get a few queries to our published nameservers not for the
109.104-111.216... record, but for the 109.216...directly.

Aug 26 13:50:42 athena named[12641]: client 193.108.155.114#53495: view ext: query (cache) '109.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 26 13:50:42 kenny named[6387]: client 193.108.155.114#61543: view external: query (cache) '109.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 26 17:10:21 kenny named[6387]: client 193.108.92.65#50992: view external: query (cache) '110.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 26 17:10:21 athena named[12641]: client 193.108.92.65#59431: view ext: query (cache) '110.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 25 08:33:52 kenny named[6387]: client 65.59.243.55#51757: view external: query (cache) '107.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 25 08:33:52 athena named[12641]: client 65.59.243.55#49414: view ext: query (cache) '107.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 23 17:45:40 athena named[12641]: client 193.108.92.65#53099: view ext: query (cache) '104.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 23 17:45:40 kenny named[6387]: client 193.108.92.65#64805: view external: query (cache) '104.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 23 22:52:46 kenny named[6387]: client 72.247.122.151#50456: view external: query (cache) '106.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 23 22:52:46 athena named[12641]: client 72.247.122.151#60317: view ext: query (cache) '106.216.80.206.in-addr.arpa/PTR/IN' denied

Is that due to some broken nameservers that can't handle the CNAME or a PTR
with 6 components, a probe, or ??

Thanks,
Justin

Matus UHLAR - fantomas

unread,
Aug 28, 2008, 6:14:37 AM8/28/08
to
On 27.08.08 11:25, Justin Pryzby wrote:
> We have CIDR/29 reverse DNS delegated to us using the CNAME hack:
>
> > 109.216.80.206.in-addr.arpa is an alias for 109.104-111.216.80.206.in-addr.arpa.
> > 109.104-111.216.80.206.in-addr.arpa domain name pointer athena.norchemlab.com.
>
> Every day we get a few queries to our published nameservers not for the
> 109.104-111.216... record, but for the 109.216...directly.
[...]

> Is that due to some broken nameservers that can't handle the CNAME or a PTR
> with 6 components, a probe, or ??

looking at that record, you seem to redirect those records to the domain
104-111.216.80.206.in-addr.arpa. that is not visible from the net. At least
authoritative nameservers for 216.80.206.in-addr.arpa. do not know anything
about that domain. That delegation is broken. You must configure NS records
for the 104-111.216.80.206.in-addr.arpa. domain to 216.80.206.in-addr.arpa.
zone for the delegation to work

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Support bacteria - they're the only culture some people have.

Mark A. Moore

unread,
Aug 28, 2008, 7:05:35 AM8/28/08
to
We will have to migrate to DNSSEC next year but have a quick question. When using DNSSEC, does it affect client machines who do normal nslookups against a BIND DNS server? When DNSSEC is configured, when is it used - only server to server communications? Been doing a lot of research and just trying to understand it a little more.

Thanks in advance for any information given.


Mark

Alan Clegg

unread,
Aug 28, 2008, 7:41:35 AM8/28/08
to
Mark A. Moore wrote:
> We will have to migrate to DNSSEC next year but have a quick question.
> When using DNSSEC, does it affect client machines who do normal nslookups
> against a BIND DNS server? When DNSSEC is configured, when is it used -
> only server to server communications? Been doing a lot of research and
> just trying to understand it a little more.

DNSSEC is an addition above and beyond the current DNS infrastructure.
You don't actually "migrate to" DNSSEC, you enable DNSSEC for your
zone(s) and enable DNSSEC validation on your recursive servers to
confirm that data that you get from other servers is also correct.

DNSSEC is the addition of digital signatures to your existing resource
record sets and won't change the way that any "non-DNSSEC" clients or
servers work.

What will change is the results that clients get when they send queries
to DNSSEC enabled validating recursive servers when they ask questions
that return signatures that don't match the returned RRsets.

These "changed results" mean that 1) the query has to be made to a
recursive server that is doing validation, 2) the returned answer comes
from a server that is providing DNSSEC signed results AND 3) the result
is "bad"; having been spoofed, poisoned, corrupted in transit, OR having
an expired signature.

With DNSSEC, instead of the recursive server sending back "bad data", it
responds with a SERVFAIL result.

There's lots of good information over at http://www.dnssec.net/

ISC welcomes you (and the rest of .gov) to the world of DNSSEC :)

AlanC

Mark A. Moore

unread,
Aug 28, 2008, 8:23:16 AM8/28/08
to
Your information was very helpful. Thx.


Mark

Barry Margolin

unread,
Aug 28, 2008, 9:32:29 PM8/28/08
to
In article <g95u8o$158l$1...@sf1.isc.org>,

Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:

> On 27.08.08 11:25, Justin Pryzby wrote:
> > We have CIDR/29 reverse DNS delegated to us using the CNAME hack:
> >
> > > 109.216.80.206.in-addr.arpa is an alias for
> > > 109.104-111.216.80.206.in-addr.arpa.
> > > 109.104-111.216.80.206.in-addr.arpa domain name pointer
> > > athena.norchemlab.com.
> >
> > Every day we get a few queries to our published nameservers not for the
> > 109.104-111.216... record, but for the 109.216...directly.
> [...]
> > Is that due to some broken nameservers that can't handle the CNAME or a PTR
> > with 6 components, a probe, or ??
>
> looking at that record, you seem to redirect those records to the domain
> 104-111.216.80.206.in-addr.arpa. that is not visible from the net. At least
> authoritative nameservers for 216.80.206.in-addr.arpa. do not know anything
> about that domain. That delegation is broken. You must configure NS records
> for the 104-111.216.80.206.in-addr.arpa. domain to 216.80.206.in-addr.arpa.
> zone for the delegation to work

I see the delegation:

; <<>> DiG 9.4.2-P1 <<>> 104-111.216.80.206.in-addr.arpa ns
@authns1.mpls.qwest.net +norec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61707
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;104-111.216.80.206.in-addr.arpa. IN NS

;; AUTHORITY SECTION:
104-111.216.80.206.in-addr.arpa. 43200 IN NS ns.norchemlab.com.
104-111.216.80.206.in-addr.arpa. 43200 IN NS ns1.norchemlab.com.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

Justin Pryzby

unread,
Aug 27, 2008, 2:09:41 PM8/27/08
to
Hi Everyone,

We have CIDR/29 reverse DNS delegated to us using the CNAME hack:

> 109.216.80.206.in-addr.arpa is an alias for 109.104-111.216.80.206.in-addr.arpa.
> 109.104-111.216.80.206.in-addr.arpa domain name pointer athena.norchemlab.com.

Every day we get a few queries to our published nameservers not for the
109.104-111.216... record, but for the 109.216...directly.

Aug 26 13:50:42 athena named[12641]: client 193.108.155.114#53495: view ext: query (cache) '109.216.80.206.in-addr.arpa/PTR/IN' denied


Aug 26 13:50:42 kenny named[6387]: client 193.108.155.114#61543: view external: query (cache) '109.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 26 17:10:21 kenny named[6387]: client 193.108.92.65#50992: view external: query (cache) '110.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 26 17:10:21 athena named[12641]: client 193.108.92.65#59431: view ext: query (cache) '110.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 25 08:33:52 kenny named[6387]: client 65.59.243.55#51757: view external: query (cache) '107.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 25 08:33:52 athena named[12641]: client 65.59.243.55#49414: view ext: query (cache) '107.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 23 17:45:40 athena named[12641]: client 193.108.92.65#53099: view ext: query (cache) '104.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 23 17:45:40 kenny named[6387]: client 193.108.92.65#64805: view external: query (cache) '104.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 23 22:52:46 kenny named[6387]: client 72.247.122.151#50456: view external: query (cache) '106.216.80.206.in-addr.arpa/PTR/IN' denied
Aug 23 22:52:46 athena named[12641]: client 72.247.122.151#60317: view ext: query (cache) '106.216.80.206.in-addr.arpa/PTR/IN' denied

Is that due to some broken nameservers that can't handle the CNAME or a PTR


with 6 components, a probe, or ??

Thanks,
Justin

0 new messages