#1200 closed defect (pending)

URL not reachable

Reported by: roland.bless@… Owned by: panda@…
Priority: tbd Milestone: ietf-100
Component: nat64 Keywords:
Cc: Clemens, Schrimpe, <csch@…> My Current Location: Canning
My MAC Address: My OS: Linux Ubuntu 17.04

Description

I tried to reach http://dl.ifip.org/db/conf/networking/networking2017/1570334752.pdf
while being connected to ietf-nat64
The Browser displays: server not found
Browser is Firefox 56.0
It works when using the "ietf" SSID.
I think it's the use of DNSSEC that causes the problem.

Attachments (1)

2017-11-16-IETF-100.pcapng (3.1 KB) - added by bless@… 11 months ago.
tcpdump trace of DNS query/responses

Download all attachments as: .zip

Change history (5)

comment:1 Changed 11 months ago by llynch@…

Cc: Clemens Schrimpe <csch@…> added

Thanks for trying the NAT64 network (SSID ietf-nat64) and reporting
your experience. As far as we can tell, the issue you reported is
either an issue of the NAT64 implementation's handling of that
specific traffic or the given application vendor's implementation.
We're collecting all the issues that come up and will pass the
reports back to the vendor at the end of the week. Hopefully this
will lead to better implementations and greater functionality for
the next meeting. If you're curious about other known issues,
please see https://tickets.meeting.ietf.org/wiki/nat64

If you have additional input on this issue please update the ticket,
if you see new issues please open additional tickets.

Also see: https://tickets.meeting.ietf.org/wiki/nat64
for a list of known issues!

Thanks -

Changed 11 months ago by bless@…

Attachment: 2017-11-16-IETF-100.pcapng added

tcpdump trace of DNS query/responses

comment:2 Changed 11 months ago by panda@…

Status: newaccepted

Thank you for reporting.

I agree that the issue is related to the DNSSEC validation as DNS64 fakes the response. My Firefox 56.0.2 and 57.0 on macOS 10.13.1 work fine because its default configuration doesn't make DNSSEC validation. Can you provide the following information as a datapoint to useful known issue information about NAT64/DNS64.

  • Operating system name and version
  • Have you enabled DNSSEC validation on your operating system (or local resolver)?
  • Have you installed any browser plugins that validate DNSSEC?

Thank you.
Hirochika Asai

comment:3 Changed 11 months ago by bless@…

  • Linux / Ubuntu 17.04 (zesty) 4.10.0-38-generic
  • I used the standard configuration of ubuntu 17.04, it seems to use a local resolver (systemd-resolve) that is DNSSEC capable
  • I have no DNSSEC validating browser plugins installed

However, I just retried to get the URL and the statistics do NOT show any DNSSEC validation failure:

systemd-resolve --statistics
DNSSEC supported by current servers: no

Transactions
Current Transactions: 0
  Total Transactions: 41162

Cache
  Current Cache Size: 11
          Cache Hits: 15
        Cache Misses: 19901

DNSSEC Verdicts
              Secure: 0
            Insecure: 0
               Bogus: 0
       Indeterminate: 0

comment:4 Changed 11 months ago by panda@…

Resolution: pending
Status: acceptedclosed

Thank you for giving us the detailed information.

Actually, our DNS64 resolvers implement DNSSEC validation for queries with the DO flag. I think your local resolver sets the DO flag and our resolver validate and respond the record without AAAA like the following.

$ dig dl.ifip.org AAAA +dnssec

; <<>> DiG 9.9.7-P3 <<>> dl.ifip.org AAAA +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25141
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dl.ifip.org.                   IN      AAAA

;; ANSWER SECTION:
dl.ifip.org.            3596    IN      CNAME   opendl.ifip-tc6.org.
opendl.ifip-tc6.org.    5760    IN      CNAME   dacs-cloud01.ewi.utwente.nl.
opendl.ifip-tc6.org.    5760    IN      RRSIG   CNAME 8 3 86400 20171128053657 20171029043949 46899 ifip-tc6.org. hs5MAz7xq50iSO/F7E6UynAvlw1cda2Yx5RR0U7/t06sVtriO2EYSb6j +G/aUk3f4/5Fi36xjXYmMn0x8wQiE/JROByqgQjqjsZcMvNSfI/l0Oq0 EJkZDiueQAOPY1YcskMONyCKIZgKBYFwd3Fh5vAMZ3zsItlQQzcYf0mW eEo=

;; AUTHORITY SECTION:
ewi.utwente.nl.         1186    IN      SOA     ns1.utwente.nl. dnsmaster.utwente.nl. 2171116194 28800 7200 604800 1200
ewi.utwente.nl.         1186    IN      RRSIG   SOA 8 3 86400 20171216230530 20171116220530 8178 ewi.utwente.nl. bPBEpB/ucRVm3CUj4TYNbW8adDyVFeizCT2qcoKKg2ZdH2PrasJf/p+Z RVXN18G1Ajla3I8MW1fSYUnkUmgXVS0yCPgpBC+F1q67MtcuzNZpWdZi IZMFlqhxJQ9h+2j7Z1Q/U7h68eQf6xlG8/uSnHg8NAf1+yRj3JY9/qut FaM=
8E3DMMIB2PMKNGRVS7JUQLMONBDU9A6Q.ewi.utwente.nl. 1186 IN RRSIG NSEC3 8 4 1200 20171210072820 20171110071308 8178 ewi.utwente.nl. PUTfQ8HoNV1Fi9IeiMpkytpVNOnFpbieF0SJjRZYiYl3mDyEO5YGmtkZ 4FswYuQnZs4BuJkEdJNtwzHpJTxp1iPDJIGHp7+LFgL56EP07GqhfhAx 6nFgsajcVqy1TNDub3rM7OG2n+0IG/rBKicULUn0O7ph+2MCtlJ531Br gUk=
8E3DMMIB2PMKNGRVS7JUQLMONBDU9A6Q.ewi.utwente.nl. 1186 IN NSEC3 1 0 10 BADC0DE1 8EAHUOMQSRMGH65Q63VPLKK4L0O683LS A RRSIG

;; Query time: 2 msec
;; SERVER: 2001:67c:370:229::7#53(2001:67c:370:229::7)
;; WHEN: Fri Nov 17 11:28:01 +08 2017
;; MSG SIZE  rcvd: 764

Without the DO flag, the responses should be like the following.

$ dig dl.ifip.org AAAA

; <<>> DiG 9.9.7-P3 <<>> dl.ifip.org AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19927
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dl.ifip.org.                   IN      AAAA

;; ANSWER SECTION:
dl.ifip.org.            1       IN      CNAME   opendl.ifip-tc6.org.
opendl.ifip-tc6.org.    5764    IN      CNAME   dacs-cloud01.ewi.utwente.nl.
dacs-cloud01.ewi.utwente.nl. 1190 IN    AAAA    64:ff9b::8259:904f

;; AUTHORITY SECTION:
utwente.nl.             3589    IN      NS      ns3.utwente.nl.
utwente.nl.             3589    IN      NS      ns2.utwente.nl.
utwente.nl.             3589    IN      NS      ns1.utwente.nl.

;; Query time: 2 msec
;; SERVER: 2001:67c:370:229::7#53(2001:67c:370:229::7)
;; WHEN: Fri Nov 17 11:27:57 +08 2017
;; MSG SIZE  rcvd: 193

This is an expected behavior according to RFC 6147, stating that the response to the A query validates, then the vDNS64 MAY perform synthesis and SHOULD set the AD bit in the answer to the client in Section 5.5. I personally think this issue may be better to be brought to v6ops WG.

Thank you.

Note: See TracTickets for help on using tickets.