feat: always answer with the NS record in the authority section #87
Conversation
if we don't do this, we're never going to see the resource record being found, because resolvers would recurse into the nameserver as the authority for this, even if intermediate nameservers know it.
|
this is needed for the onboarding site to confirm the dns is correctly setup, because it will recurse all nameservers up to api.distributed.press who won't know anything about this record |
|
Related: #69 (comment) |
dns/index.ts
Outdated
| type: dns2.Packet.TYPE.NS, | ||
| class: dns2.Packet.CLASS.IN, | ||
| ttl: TTL, | ||
| ns: 'api.distributed.press.' |
There was a problem hiding this comment.
You can get the host param in apiBuilder and should pass it to the DNS init defined here
Maybe respond to CNAME with the host too?
There was a problem hiding this comment.
Maybe respond to CNAME with the host too?
it should query A and AAAA addresses for the host and respond with that, because CNAME is frowned upon on the apex domain (some implementations ignore it but on the wild i've only found it on email notifications from twilio)
|
Looks like asking for NS wouldn't work. |
I tested it with doh.js pointing to CF's DOH and it returned answers for NS sutty.nl though I'll check tomorrow |
|
Yeah, NS for the top level seems to work, not for the |
This is what this PR fixes! It doesn't work because the resolver goes asking for the NS record and the domain NS replies that it's api.distributed.press. which works, but actually it's saying "you should ask api.distributed.press." and it currently can't answer. You can test it like this to see I'm asking for the NS record, returned by DO, but it continues and reaches DP, who can only respond with TXT records so not what I'm asking: |
if we don't do this, we're never going to see the resource record being found, because resolvers would recurse into the nameserver as the authority for this, even if intermediate nameservers know it.